{"id":782,"date":"2021-05-21T08:34:17","date_gmt":"2021-05-21T08:34:17","guid":{"rendered":"https:\/\/shreyapohekar.com\/blogs\/?p=782"},"modified":"2022-02-09T19:06:41","modified_gmt":"2022-02-09T19:06:41","slug":"dont-just-sanitize-but-also-escape-a-fable-of-sanitize_text_field","status":"publish","type":"post","link":"https:\/\/shreyapohekar.com\/blogs\/dont-just-sanitize-but-also-escape-a-fable-of-sanitize_text_field\/","title":{"rendered":"Dont just sanitize but also escape – A fable of sanitize_text_field"},"content":{"rendered":"\n

Hey infosec fam!! Recently I was testing out an image upload functionality on a wordpress plugin that led me to stored XSS. In this blog post, I will be writing about an interesting story of how I got XSS even when a filter (sanitize_text_field) was in place.<\/p>\n\n\n\n

Let’s get started!<\/p>\n\n\n\n

Scenario<\/h2>\n\n\n\n

The plugin has the image upload functionality where image can be uploaded either through the default list or from the WordPress uploads folder. I was testing out other parameters for XSS where I found that after the image is taken from the wp-uploads, the image path is mentioned in the response as a URL to wp-content\/uploads.<\/p>\n\n\n\n

This was interesting and the first thing that came to my mind was to break out of the src to insert an XSS payload. I inserted ” to break out of src attribute and insert onerror attribute so as to execute javascript. <\/p>\n\n\n\n

I used this payload:- http:\/\/x.x.x.x\/image\"onerror=alert(1);\/\/.png<\/code><\/strong> while intercepting through burp.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

When I opened the list of the added items, the malformed HTTP URL of the image got loaded and I got an XSS popup. Yayyyyy!!<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

But did you noticed one thing? The double quotes<\/code> in the payload got escaped. <\/p>\n\n\n\n

Wondering why XSS happened in the first place?! Lets get to the code review and find out.<\/p>\n\n\n\n

Code Review<\/h2>\n\n\n\n

Since I was testing on a wordpress plugin, I had the option to see whats happening behind the scenes.<\/p>\n\n\n\n

So here comes the interesting part! The reason why you see a backslash(\\) is because sanitize_text_field<\/strong> is used while taking the image input.<\/p>\n\n\n\n

$results = $wpdb->insert(\n                     $table_name,\n                     array(\n                         'title' => sanitize_text_field($_POST['title']),\n                         'url' => sanitize_text_field($_POST['url']),\n                         'image_url' => sanitize_text_field($_POST['image_file']),<\/strong>\n                         'sortorder' => sanitize_text_field($_POST['sortorder']),\n                         'date_upload' => time(),\n                         'target' => sanitize_text_field($_POST['target']),\n                     ),\n                     array(\n                         '%s',\n                         '%s',\n                         '%s',\n                         '%d',\n                         '%s',\n                         '%d',\n                     )\n                 );<\/pre>\n\n\n\n
Let’s talk about what this filter is and what does it sanitize!<\/p>\n\n\n\n
sanitize_text_field<\/h2>\n\n\n\n
From the wordpress official documentation<\/p>\n\n\n\n
Sanitizes a string from user input or from the database.<\/p><\/blockquote>\n\n\n\n
Basic usage<\/h3>\n\n\n\n
<?php sanitize_text_field( $str<\/code> ) ?><\/code><\/pre>\n\n\n\n
So if $str contains \" | ' | < | &<\/code>  characters, the function will add a backslash(\\) so as to escape the original functionality of that character. <\/p>\n\n\n\n
So when I inserted \"<\/code> as part of the payload, it did escaped the double quotes by adding \\ therefore making it \\\"<\/code><\/p>\n\n\n\n
But the thing to note here is, we don’t us sanitize_text_fields when the reflection\/sink from your input is gonna be the part of src<\/code> attribute<\/p>\n\n\n\n
Still wondering why??<\/h2>\n\n\n\n
Let’s simplify. Here comes the concept of XSS contexts<\/span><\/strong>.  You as an attacker need to understand and identify where in response,  the user-controlled data appears. The next thing to identify is the filters or any other processing that is in place.<\/p>\n\n\n\n
The user controlled data can be reflected\/stored in:<\/p>\n\n\n\n
  • HTML tags<\/strong>: When the context is between the HTML tags, you need to introduce new HTML tags that can execute javascript.<\/li>
  • HTML tag attributes<\/strong>: When the context is into HTML tag attribute, you can terminate the attribute value with double quotes<\/code> and insert a new attribute that can execute javascript. There’s also a possibility to close the current tag with “> and insert <script>alert(1)<\/script>. But you can expect <> to be escaped\/blocked 99% times so mostly you will have to play around the `double quotes\/single quotes`.<\/li>
  • In javascript: When the context is in javascript, you can introduce new HTML tags that can trigger the execution of javascript. Example:<\/li><\/ul>\n\n\n\n
    <\/script><img src=x onerror=prompt(1)><\/pre>\n\n\n\n
    If the user controlled input is inside a string literal, then you can easily breakout with<\/p>\n\n\n\n
    ';alert(1)\/\/<\/pre>\n\n\n\n
    • Javascript template literals<\/strong>: These are the string literals that allow embedded Javascript expressions. These expressions are evaluated and then concatenated with the surrounding text.<\/li><\/ul>\n\n\n\n
      Consider a script that takes in username and print Hi <username><\/p>\n\n\n\n
      document.getElementById('username').innerText = `Hi there!, ${user.userName}.`;<\/pre>\n\n\n\n
      With template literals, there is no need to escape from the quotes. You just simply have to write your payload inside ${..}<\/p>\n\n\n\n
      <script>\n...\nvar userName = '${alert(document.dmain}';  \/\/user controlled input\n...\n<\/script><\/pre>\n\n\n\n
      And the alert will work.<\/p>\n\n\n\n
      That was the gist of what contexts are and how they work. <\/p>\n\n\n\n
      Let’s get back to context that we’ll be dealing with.<\/h3>\n\n\n\n
      In our scenario, the context is inside HTML tag attribute<\/strong>. The backslash(\\) added by sanitize_text_field now becomes a part of URL and therefore is unable to escape the double quotes and hence the src attribute is closed. The other part of the payload onerror=alert(1);\/\/<\/strong><\/code> now becomes another valid attribute. \/\/<\/code> is added so that the remaining part of <img<\/strong><\/code> tag doesnt cause any barrier.<\/p>\n\n\n\n
      And tada!!!  Its XSS \ud83d\ude42<\/p>\n\n\n\n
      Research on other methods<\/h2>\n\n\n\n
      In the recital above, what we learn is: Just having a filter in place doesnt necessarily mean that your code is attack-proof. A proper understanding of what filters are filtering out is important.<\/p>\n\n\n\n
      I tested down the payload on all the available filters an found 2 more places giving the same effect as sanitize_text_field. <\/p>\n\n\n\n
      • wp_strip_all_tags<\/li>
      • strip_tags<\/li><\/ul>\n\n\n\n
        \"\"<\/figure>\n\n\n\n
        Here the outcome is pretty obvious from the name of filter that it will just stip tags.<\/p>\n\n\n\n
        So If by any chance these methods are used for a parameter whose sink is in src attribute, it still makes you vulnerable to the above scenario,<\/p>\n\n\n\n
        Method that can be used<\/h2>\n\n\n\n
        These are a bunch of filters that can do the work for you. In this section. I have collated a list of such filters that behave differently for a single payload: \" onerror=alert(1);\/\/<\/code><\/p>\n\n\n\n
        • urlencode<\/strong> : URL-encodes string<\/li><\/ul>\n\n\n\n
          If the method is changed from sanitize_text_field to urlencode, the xss is now gone. See image below.<\/p>\n\n\n\n
          \"\"<\/figure>\n\n\n\n
          • rawurlencode<\/strong>: URL-encode according to RFC 3986<\/li><\/ul>\n\n\n\n
            \"\"<\/figure>\n\n\n\n
            • esc_textarea<\/strong>: Escaping for textarea values.<\/li><\/ul>\n\n\n\n
              \"\"<\/figure>\n\n\n\n
              • esc_html<\/strong>: Escaping for HTML blocks.<\/li><\/ul>\n\n\n\n
                \"\"<\/figure>\n\n\n\n
                • esc_js<\/strong>: Escape single quotes, htmlspecialchar \u201d &, and fix line endings.<\/li><\/ul>\n\n\n\n
                  \"\"<\/figure>\n\n\n\n
                  • sanitize_key<\/strong>: Sanitizes a string key. Keys are used as internal identifiers. Lowercase alphanumeric characters, dashes, and underscores are allowed.<\/li><\/ul>\n\n\n\n
                    \"\"<\/figure>\n\n\n\n
                    Every filter method is created for a reason and developers need to understand which one to use when.<\/p>\n\n\n\n
                    Key takeaways<\/h2>\n\n\n\n
                    Finally, in this last section, I want to list a few takeaways<\/p>\n\n\n\n
                    • Always go through the documentation of methods and read about what are they exactly filtering and does that match your use case.<\/li>
                    • If you are still unsure if the filter can protect you from XSS, try using filters that are nested. For example $str = esc_attr(esc_js($GET['param']))<\/code>. The combination can be any according to the case in point. This is a nice approach I found while doing source-code review of different plugins.<\/li>
                    • As a pentester, do not skip testing out a functionality if you have already found filters in the source code review. Coz stories like that of sanitize_text_field can happen to anyone.<\/li><\/ul>\n\n\n\n
                       That’s all for this blog post. Thanks for reading! Hope you enjoyed reading my research.<\/p>\n\n\n\n
                      See you in the next one! Until then, happy hunting \ud83d\ude42 <\/p>\n","protected":false},"excerpt":{"rendered":"
                      The post talks about an interesting find of XSS even when the filter was used. It also covers the mistakes that a developer makes while sanitizing input.<\/p>\n","protected":false},"author":1,"featured_media":820,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"ocean_post_layout":"","ocean_both_sidebars_style":"","ocean_both_sidebars_content_width":0,"ocean_both_sidebars_sidebars_width":0,"ocean_sidebar":"","ocean_second_sidebar":"","ocean_disable_margins":"enable","ocean_add_body_class":"","ocean_shortcode_before_top_bar":"","ocean_shortcode_after_top_bar":"","ocean_shortcode_before_header":"","ocean_shortcode_after_header":"","ocean_has_shortcode":"","ocean_shortcode_after_title":"","ocean_shortcode_before_footer_widgets":"","ocean_shortcode_after_footer_widgets":"","ocean_shortcode_before_footer_bottom":"","ocean_shortcode_after_footer_bottom":"","ocean_display_top_bar":"default","ocean_display_header":"default","ocean_header_style":"","ocean_center_header_left_menu":"","ocean_custom_header_template":"","ocean_custom_logo":0,"ocean_custom_retina_logo":0,"ocean_custom_logo_max_width":0,"ocean_custom_logo_tablet_max_width":0,"ocean_custom_logo_mobile_max_width":0,"ocean_custom_logo_max_height":0,"ocean_custom_logo_tablet_max_height":0,"ocean_custom_logo_mobile_max_height":0,"ocean_header_custom_menu":"","ocean_menu_typo_font_family":"","ocean_menu_typo_font_subset":"","ocean_menu_typo_font_size":0,"ocean_menu_typo_font_size_tablet":0,"ocean_menu_typo_font_size_mobile":0,"ocean_menu_typo_font_size_unit":"px","ocean_menu_typo_font_weight":"","ocean_menu_typo_font_weight_tablet":"","ocean_menu_typo_font_weight_mobile":"","ocean_menu_typo_transform":"","ocean_menu_typo_transform_tablet":"","ocean_menu_typo_transform_mobile":"","ocean_menu_typo_line_height":0,"ocean_menu_typo_line_height_tablet":0,"ocean_menu_typo_line_height_mobile":0,"ocean_menu_typo_line_height_unit":"","ocean_menu_typo_spacing":0,"ocean_menu_typo_spacing_tablet":0,"ocean_menu_typo_spacing_mobile":0,"ocean_menu_typo_spacing_unit":"","ocean_menu_link_color":"","ocean_menu_link_color_hover":"","ocean_menu_link_color_active":"","ocean_menu_link_background":"","ocean_menu_link_hover_background":"","ocean_menu_link_active_background":"","ocean_menu_social_links_bg":"","ocean_menu_social_hover_links_bg":"","ocean_menu_social_links_color":"","ocean_menu_social_hover_links_color":"","ocean_disable_title":"default","ocean_disable_heading":"default","ocean_post_title":"","ocean_post_subheading":"","ocean_post_title_style":"","ocean_post_title_background_color":"","ocean_post_title_background":0,"ocean_post_title_bg_image_position":"","ocean_post_title_bg_image_attachment":"","ocean_post_title_bg_image_repeat":"","ocean_post_title_bg_image_size":"","ocean_post_title_height":0,"ocean_post_title_bg_overlay":0.5,"ocean_post_title_bg_overlay_color":"","ocean_disable_breadcrumbs":"default","ocean_breadcrumbs_color":"","ocean_breadcrumbs_separator_color":"","ocean_breadcrumbs_links_color":"","ocean_breadcrumbs_links_hover_color":"","ocean_display_footer_widgets":"default","ocean_display_footer_bottom":"default","ocean_custom_footer_template":"","ocean_post_oembed":"","ocean_post_self_hosted_media":"","ocean_post_video_embed":"","ocean_link_format":"","ocean_link_format_target":"self","ocean_quote_format":"","ocean_quote_format_link":"post","ocean_gallery_link_images":"on","ocean_gallery_id":[],"footnotes":""},"categories":[328,321,329,327,257,330],"tags":[298,322,323,71,126,326,324,325,8],"class_list":["post-782","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-code-vigilant","category-owasp-top-10","category-php","category-source-code-review","category-web-application","category-xss","tag-code-review","tag-codeviilant","tag-filters","tag-linux","tag-php","tag-research","tag-sanitize_text_field","tag-stroed-xss","tag-xss","entry","has-media"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t