Sanitizing Input in Web Apps (Part 2)
In Part 1 of our web app sanitation series, we looked at unsanitized user-controlled data inserted directly into the HTML response of a web page. This entry focuses on a more specific case: user-controlled data being used within a web app in areas like attributes of HTML tags.
Case 2: Data Used as an Attribute within a Tag or in Other Sensitive Parts of the HTML Source (DUAAAWATOIOSPOTHTMLS)
We will look at an example to give users an idea about how data (even “sanitized” data) can be used to break a web app, leading to a vulnerability and chance of attack.
Example 1: Image File Name
Consider a web application that takes the following input:
http://example.com/app_product_picture.php?product=super_gizmo
That gives the following output (in HTML)
———————————————-
———————————————-
Now let’s say this page is created using the following PHP code:
———————————————-
———————————————-
This script displays an image stored in the ./img directory. However, because the filename of the image to be displayed relies on unsanitized user input, an XSS vulnerability is present.
In Part 1, we showed how filtering angle brackets can prevent certain types of XSS attacks. In this case, even filtering brackets won’t fix the problem. Consider the following input:
http://example.com/app_product_picture.php?product=super_gizmo.jpg” onload=alert(1); y=”.jpg
The resulting HTML would be:
———————————————-
———————————————-
Since “./img/super_gizmo.jpg” is a valid image, the javascript onload event handler will execute the code as soon as the image is loaded. Since the attacker can influence the attributes using quotations or apostrophes, it is possible for them to execute code within the context of the page being viewed if the data isn’t sanitized first.
Consider the following filter using HTML special characters:
———————————————-
———————————————-
The idea is to prevent users from breaking out of the “src” attribute. Since quotation marks and apostrophes are standard HTML attribute delimiters, filtering them from user input is an effective solution.
It’s better coding practice to not use data in this way to begin with. For such an application, it would be better if the product was identified by some number or character string that points to an object or array element which would contain a reference to the image to be displayed. This way, user data isn’t used directly within the HTML source at all.
However, the preceding example should give readers a good idea of how fragile user-influenced data can make an application.
Stick around for the next episode– Case 3: Sanitizing SQL Queries FTW
Each Tuesday, Security Musings features a topic to help educate our readers about security. For more information about Gemini Security Solutions’ security education capabilities, contact us!
August 3rd, 2009 at 10:33 am
[...] #1 – Sanitize Those Apps: A few weeks ago we featured the @geminisecurity post “Sanitizing Input in Web Apps (Part 1).” We ranked it at number one to emphasize the importance of sanitizing input for the web (and anything else, for that matter). That’s why when @geminisecurity rolled out with part two of their “Sanitizing Web Apps” article, we knew that it needed to fill the number one slot again. Sanitizing input for web apps is one of the basic tenants for securing web apps. When we forget to sanitize input, or skip what might seem to be a rather minor step, we’re doing ourselves and users a huge disservice. It goes back to our motto of doing the basics and doing them well; it saves you, and everyone else, a lot of headache in the end. More than that though, it helps keep everyone safer. And at the end of the day, isn’t that what we all want? While we step off our soapbox, head over to @geminisecurity to read the full post. [...]
September 9th, 2009 at 11:17 pm
[...] Last time, in our web app sanitation series, we looked at unsanitized input as part of an html tag or attribute. This entry focuses on sanitizing SQL queries. [...]