If you’re planning to take the SY0-501 version of the Security+ exam, you should understand web application attacks. Web applications are hosted on servers, so it’s important to understand the basics related to preventing web application attacks.
For example, can you answer this question?
Q. While creating a web application, a developer adds code to limit data provided by users. The code prevents users from entering special characters. Which of the following attacks will this code MOST likely prevent?
A. Man-in-the-browser
B. Amplification
C. XSS
D. Domain hijacking
More, do you know why the correct answer is correct and the incorrect answers are incorrect? The answer and explanation are available at the end of this post.
Injection Attacks
There are multiple types of injection attacks beyond DLL injection and SQL injection attacks discussed previously in this chapter. Another type of injection attack is a command injection attack.
In some cases, attackers can inject operating system commands into an application using web page forms or text boxes. Any web page that accepts input from users is a potential threat. Directory traversal is a specific type of command injection attack that attempts to access a file by including the full directory path, or traversing the directory structure.
For example, in Unix systems, the passwd file includes user logon information, and it is stored in the /etc directory with a full directory path of /etc/passwd. Attackers can use commands such as../../etc/passwd or /etc/passwd to read the file. Similarly, they could use a remove directory command (such as rm -rf) to delete a directory, including all files and subdirectories. Input validation can prevent these types of attacks.
Cross-Site Scripting
Cross-site scripting (XSS) is another web application vulnerability that can be prevented with input validation techniques. Attackers embed malicious HTML or JavaScript code into a web site’s code. The code executes when the user visits the site.
You may be wondering why the acronym isn’t CSS instead of XSS. The reason is that web sites use Cascading Style Sheets identified as CSS and CSS files are not malicious.
The primary protection against XSS attacks is at the web application with sophisticated input validation techniques. Developers should avoid any methods that allow the web page to display untrusted data. Additionally, OWASP strongly recommends the use of a security encoding library. When implemented, an encoding library will sanitize HTML code and prevent XSS attacks. OWASP includes more than 10 rules that developers can follow to prevent XSS attacks.
It’s also important to educate users about the dangers of clicking links. Some XSS attacks send emails with malicious links within them. The XSS attack fails if users do not click the link.
Cross-Site Request Forgery
Cross-site request forgery (XSRF or CSRF) is an attack where an attacker tricks a user into performing an action on a web site. The attacker creates a specially crafted HTML link and the user performs the action without realizing it.
As an innocent example of how HTML links create action, consider this HTML link: http://www.google.com/search?q=Success. If users click this link, it works just as if the user browsed to Google and entered Success as a search term. The ?q=Success part of the query causes the action.
Many web sites use the same type of HTML queries to perform actions. For example, imagine a web site that supports user profiles. If users wanted to change profile information, they could log on to the site, make the change, and click a button. The web site may use a link like this to perform the action:
http://getcertifiedgetahead.com/edit?action=set&key=email&value=you@home.com
Attackers use this knowledge to create a malicious link. For example, the following link could change the email address in the user profile, redirecting the user’s email to the attacker:
http://getcertifiedgetahead.com/edit?action=set&key=email&value=hacker@hackersrs.com
Although this shows one possibility, there are many more. If a web site supports any action via an HTML link, an attack is possible. This includes making purchases, changing passwords, transferring money, and much more.
Web sites typically won’t allow these actions without users first logging on. However, if users have logged on before, authentication information is stored on their system either in a cookie or in the web browser’s cache. Some web sites automatically use this information to log users on as soon as they visit. In some cases, the XSRF attack allows the attacker to access the user’s password.
Users should be educated on the risks related to links from sources they don’t recognize. Phishing emails often include malicious links that look innocent enough to users, but can cause significant harm. If users don’t click the link, they don’t launch the XSRF attack.
However, just as with cross-site scripting, the primary burden of protection from XSRF falls on the web site developers. Developers need to be aware of XSRF attacks and the different methods used to protect against them. One method is to use dual authentication and force the user to manually enter credentials prior to performing actions. Another method is to expire the cookie after a short period, such as after 10 minutes, preventing automatic logon for the user.
Many programming languages support XSRF tokens. For example, Python and Django, two popular web development languages, require the use of an XSRF token in any page that includes a form, though these languages call them CSRF tokens. This token is a large random number generated each time the form is displayed. When a user submits the form, the web page includes the token along with other form data. The web application then verifies that the token in the HTML request is the same as the token included in the web form.
The HTML request might look something like this:
getcertifiedgetahead.com/edit?action=set&key=email&value=you@home.com&token=1357924
The token is typically much longer. If the website receives a query with an incorrect error, it typically raises a 403 Forbidden error. Attackers can’t guess the token, so they can’t craft malicious links that will work against the site.
Q. While creating a web application, a developer adds code to limit data provided by users. The code prevents users from entering special characters. Which of the following attacks will this code MOST likely prevent?
A. Man-in-the-browser
B. Amplification
C. XSS
D. Domain hijacking
Answer is C. A cross-site scripting (XSS) attack can be blocked by using input validation techniques to filter special characters such as the < and > characters used in HTML code. None of the other listed attacks require the use of special characters.
A man-in-the-browser attack exploits vulnerabilities in browsers to capture user data entries.
An amplification attack increases the amount of data sent to a victim to overwhelm it.
A domain hijacking attack changes the domain registration of a domain name without permission of the owner.