Miscellaneous Security

Reading time: 2 – 4 minutes

Photo: Ŕooners

This is the third-part in a ten-part-series describing the OWASP Top 10. (See all the OWASP Top 10)

What is Malicious File Execution

Some web applications allow the user to specify input that is used directly into file streams or allows the user to upload files to the server. At a later time the web application accesses the user supplied input in the web applications context. By doing this, the web application is allowing the potential for malicious file execution.

When an application allows user to modify file streams, the application is trusting the user to operate within certain “rules” and may assume the user won’t break these rules.

If there aren’t preventions in place, an attacker can exploit the rules by attempting to include files stored on remote or local file systems.

Web applications that are vulnerable to malicious file execution break the simple security rule of trusting user input.

Allowing malicious file execution to exist in a web application can lead to the complete compromise of the server.

Examples of Malicious File Execution

Typical examples of malicious file execution are remote file includes and local file includes. Most people think of these as PHP functions, however, that does not mean an ASP or JSP server isn’t susceptible to malicious file execution vulnerabilities.

Here is a common example, Imagine the PHP function:

include $_REQUEST['filename'];

An attacker can then specify a file name of a remote URL that they control, say http://evilhacker.com/attack.php

How Do You Prevent Malicious File Execution

Malicious file execution needs to be prevented from the design stage. If the design stage of the web application has already been completed, then extra precaution needs to be taken.

Developers need to pay particular attention to code access security mechanisms to ensure that file names supplied by or influenced by the user do not allow security controls to be obviated.

Web applications should not allow users to insert input into a server-based resource. However, if the ability is needed, then developers need to be extra cautious about what input they accept. Developers should insure that file names supplied by the user do not allow security controls to be bypassed.

General preventions that can be taken include:

• Strongly Validating user input using an only “accept known good” input.
• Adding firewall rules that prevent web servers from making new connections to external websites will aid in preventing remote file include vulnerabilities.
• Implementing a sandbox to isolate applications from one another.

Depending on your environment, specific preventions can also be taken. For instance, with J2EE developers should ensure that the security manager is enabled and properly configured. More information about specific environment preventions can be found at OWASP’s full article on malicious file execution.

Reading time: 2 – 2 minutes

When developing a security strategy for web applications many companies have no idea where to begin. The Open Web Application Security Project (OWASP) understood this problem and developed the OWASP Top 10.

The OWASP top 10 are the top 10 vulnerabilities that are found in web applications. If you have an hour or don’t want to read all of these posts, you can simply watch a video.

If you are a developer, you should understand these vulnerabilities. Understanding them is critical into introducing less vulnerabilities into your code.

The OWASP Top 10:
A1 – Cross Site Scripting (XSS)
A2 – Injection Flaws
A3 – Malicious File Execution
A4 – Insecure Direct Object Reference
A5 – Cross Site Request Forgery (CSRF)
A6 – Information Leakage and Improper Error Handling
A7 – Broken Authentication and Session Management
A8 – Insecure Cryptographic Storage
A9 – Insecure Communications
A10 – Failure to Restrict URL Access

Reading time: 4 – 6 minutes

Photo: Urban Woodswalker

If it hasn’t already, Cross-Site Scripting (XSS) will soon be replacing SQL injection as the new buzzword in the security sector. XSS will continually be a topic on this blog as well as others [1],[2],[3],[4]. Due to this fact, I think a primer would be a good idea for those who don’t know or understand this problem.

Many articles have been written about Cross-Site Scripting and if you want to have a better understanding of the problem, I suggest you read those documents (Links at the bottom of the post).

Basically, There are 3 types of Cross-Site Scripting:

1. Stored/Non-Reflective/Persistent Cross Site Scripting (User visits the XSS’ed page)
2. Non-Stored/Reflective/Reflected Cross Sited Scripting (User clicks a link that embeds the script into the loaded page)
3. DOM Based Cross Site Scripting (please read this article)

All of these names make it confusing for a first timer to understand XSS. There really should be a better web application security standards organization. Here is a breakdown of Persistent XSS and Reflective XSS. These are the big two that most people talk about when they are referring to Cross Site Scripting. If you understand these well, you will be able to participate in 90% of XSS conversations.

Persistent Cross-Site Scripting

Persistent XSS is arguably more dangerous than reflective XSS. This attack embeds the malicious script permanently into the web application. The script will then wait until people access the page it is located on.

Here is an attack using Persistent Cross-Site Scripting:

1. The victim visits a website they trust, amazon.com.
2. A script has been inserted by an attacker on a page they happen to visit while on amazon.com.
3. The script executes in the context of amazon.com.
4. The victim is then compromised.

Note: Obviously, someone can increase the chances of the victim visiting this page (step 2) through social engineering, phishing, etc.

Reflective Cross-Site Scripting

These are the ones the media usually reports on. [1],[2],[3]. In this attack, some type of social engineering is involved for the attack to be successful.

Here is an attack, using Reflective Cross-Site Scripting:

1. The victim gets an email/Instant Message that contains a link.
2. The victim clicks the link. (Requires User Intervention)
3. A script has been inserted by an attacker on the page they then visit.
4. The script executes in the context of that site.
5. The victim is then compromised.

Note: I want to reiterate that this attack requires some type of user intervention (step 2).

Why is Cross-Site Scripting Bad?

Cross-Site Scripting can lead to all sorts of different exploits, including system compromise. For an attacker to do this, they need to break out of the browser’s context. We have seen examples that breaking out of the browser is not that hard to do.

In addition, an attacker can also establish a bi-directional channel using iframes. This creates a man-in-the-middle attack. The attacker can then intercept key strokes, use the victim as an intranet portscanner, and even stealing creditials. The attacker is only limited by their knowledge of scripting.

Example of a bi-directional channel

Hopefully, this gives you a better understanding of Cross-Site Scripting. Feel free to leave comments if you don’t understand something and I will address it in the article.

Additional Resources:

Cross-Site Scripting (XSS) FAQ

OWASP Guide to XSS

XSS Video Tutorial (via youtube)

XSS Attack API