|Join hundreds of other Developers and InfoSec professionals for Training, Sessions and Community at our first conference of 2019|
[AppSec Tel Aviv, May 26-30th]
Testing for AJAX Vulnerabilities (OWASP-AJ-001)
This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.
OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here
- 1 Introduction
- 2 Attacks and Vulnerabilities
- 3 Major Attacks
- 4 References
- Increased attack surface with many more inputs to secure
- Exposed internal functions of the application
- Client access to third-party resources with no built-in security and encoding mechanisms
- Failure to protect authentication information and sessions
- Blurred line between client-side and server-side code, possibly resulting in security mistakes
Attacks and Vulnerabilities
Secondly, in the case of accessing an AJAX page on a non-SSL connection, the subsequent XMLHttpRequest calls are also not SSL encrypted. Hence, the login data is traversing the wire in clear text. Using secure HTTPS/SSL channels, which the modern day browsers support, is the easiest way to prevent such attacks from happening.
XMLHttpRequest(XHR) objects retrieve the information of all the servers on the web. This could lead to various other attacks such as SQL Injection, Cross Site Scripting (XSS), etc.
Increased Attack Surface
Unlike traditional web applications that execute completely on the server, AJAX applications extend across the client and server, which gives the client some power. This throws in additional ways to potentially inject malicious content.
SQL Injection attacks (see Testing for SQL Injection) are remote attacks on the database in which the attacker modifies SQL statements before they are processed by the DBMS.
Typical SQL Injection attacks could be as follows (examples refer to Microsoft SQL Server)
SELECT id FROM users WHERE name='' OR 1=1 AND pass='' OR 1=1 LIMIT 1;
This query will always return one row (unless the table is empty), and it is likely to be the first entry in the table. For many applications, that entry is the administrative login - the one with the most privileges.
Note. The code fragment above tries to match userid and password values (obtained in input) with attributes name, pass of users; consequently, it appears that users is storing passwords in clear text, a practice which is not recommendable.
SELECT id FROM users WHERE name='' AND pass=''; DROP TABLE users;
The above set of SQL statements drops the table users, causing a Denial of Service. This consequence is possible on DBMS allowing concatenation of multiple statements.
Cross Site Scripting
Also, an XSS attack could send requests for specific pages other than the page the user is currently looking at. This allows the attacker to actively look for certain content, potentially accessing the data.
The XSS payload can use AJAX requests to autonomously inject itself into pages and easily re-inject the same host with more XSS (like a virus), all of which can be done with no hard refresh. Thus, XSS can send multiple requests using complex HTTP methods to propagate itself invisibly to the user.
This will just redirect the page to an unknown and malicious page after logging into the original page from where the request was made.
Client Side Injection Threats
- XSS exploits can give access to sensitive client-side data, and can also modify client-side code.
- DOM Injection is a type pf XSS injection which happens through the sub-objects, document location, document.URL, or document.referrer of the Document Object Model(DOM)
<SCRIPT> var pos=document.URL.indexOf("name=")+5; document.write(document.URL.substring(pos,document.URL.length)); </SCRIPT>
- JSON/XML/XSLT Injection - Injection of malicious code in the XML content
Cross Site Request Forgery (CSRF)
Browser Based Attacks
Attacks that target Web browser and Web application vulnerabilities are often conducted by HTTP and, therefore, may bypass filtering mechanisms in place on the network perimeter. In addition, the widespread deployment of Web applications and Web browsers gives attackers a large number of easily exploitable targets. For example, Web browser vulnerabilities can lead to the exploitation of vulnerabilities in operating system components and individual applications, which can lead to the installation of malicious code, including bots.
The Samy and Spaceflash worms both spread on MySpace, changing profiles on the hugely popular social-networking Web site. In the case of Samy (see Technical explanation of The MySpace Worm), MySpace input validation controls prevent the injection of <SCRIPT> tags, however failed to consider all HTML tags, such as DIV. The article is a good example demonstrating how hard it is to perform input validation (particularly if you try to do it following a black list based approach). AJAX was used to inject a worm into the MySpace profile of any user viewing infected page and forced any user viewing the infected page to add the user “Samy” to his friend list. It also appended the words “Samy is my hero” to the victim's profile
Yahoo! Mail Attack
- Billy Hoffman, "Ajax(in) Security" - http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Hoffman.pdf
- Billy Hoffman, "Analysis of Web Application Worms and Viruses - http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Hoffman_web.pdf ",SPI Labs
- Billy Hoffman, "Ajax Security Dangers" - http://www.spidynamics.com/assets/documents/AJAXdangers.pdf ",SPI Labs
- “Ajax: A New Approach to Web Applications”, Adaptive Path - http://www.adaptivepath.com/publications/essays/archives/000385.php Jesse James Garrett
- http://en.wikipedia.org/wiki/AJAX AJAX
- http://ajaxpatterns.org AJAX Patterns
- Billy Hoffman, "Ajax Security Dangers" - http://rmccurdy.com/scripts/docs/spidynamics/AJAXdangers.pdf ",SPI Labs