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!