Ajax Secure Development Guide

/ Security Guide

Section 1. Ajax Vulnerabilities and Countermeasures

Ajax (Asynchronous JavaScript and XML) is a web application development method that uses asynchronous JavaScript to exchange XML data with a web server via the HTTP protocol. Unlike traditional web models, it allows web pages to be updated dynamically without decreasing response speeds. Ajax is not a single technology but rather a methodology or pattern that combines various technologies. This document covers security countermeasures for risk factors that can arise in Ajax. Furthermore, since Ajax is often implemented alongside existing web architectures, security practices should be applied during development by considering not only the contents of this guideline but also vulnerabilities occurring in traditional web environments (such as the OWASP Top 10).

1. Input Value Validation

A. XSS (Cross-site Scripting) in Ajax

XSS (Cross-site Scripting) is one of the most common application-layer attacks used by hackers to surreptitiously infiltrate web applications. For Ajax, which is composed of JavaScript, XSS can be a fatal attack. Risk factors have been classified based on the type of attack technique used to execute malicious scripts on general users and the point of occurrence. Security countermeasures for XSS vulnerabilities are commonly applied to these vulnerabilities.

(1) Risk Factors
Malformed JS Object Serialization (Improper use of JavaScript objects)

Because JavaScript provides object-oriented programming, users can create many arbitrary objects as desired. Objects can be created using new Object() or through code such as the following:

message = {
from : "john@example.com",
to : "jerry@victim.com",
subject : "I am fine",
body : "Long message here",
showsubject : function(){document.write(this.subject)}
};

The code above is an example of a message object created with the fields necessary for writing an email. This message object is then used via JavaScript code or Ajax. A malicious user could insert a malicious script into a post or email subject to perform an XSS attack on users who view the email. Since JavaScript objects can possess both methods and critical data, improper use of JavaScript objects can create security loopholes for malicious code injection, allowing other users to be attacked.

JSON pair injection

JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format used when sending and receiving data. It is based on a subset of the ECMAScript language (a part of JavaScript) and defines a set of formatting rules to create structured data. While its format follows JavaScript syntax, it is independent of programming languages or platforms and can be used in many languages such as C, C++, Java, JavaScript, Perl, and Python. JSON provides a very effective data exchange format for Web 2.0 applications. Developers very frequently use JSON in Ajax to retrieve necessary information from the DOM, but the following problems exist. Below is simple code that creates a bookmark object: {"bookmarks":[{"Link":"www.example.com","Desc":"Interesting link"}]} In the code above, an attacker could execute an XSS attack by inserting a malicious script into the Desc or Link sections.

JS Array poisoning

The JS array is one of the most important objects for object serialization, and it is effective for easily utilizing platforms or cross-language frameworks. Poisoning a JS array can ruin the DOM context, and XSS attacks can be performed on users by inserting a simple script into a JS array. Below is a simple JS array example.

Example

new Array(“Laptop”, “Thinkpad”, “T60”, “Used”, “900$”, “It is great and I have used it for 2 years <script>alert('xss');</script>”)

The array above is intended to transmit data during a used laptop transaction on an auction site. If the array object is not handled properly, the server-side must validate the script inserted by the user in the final field. This attack technique can jeopardize the browser or be used as an attack method by an attack agent.

Manipulated XML stream

Ajax loads XML from various locations. These XML blocks are initiated by running web services such as SOAP, REST, or XML-RPC. These web services are utilized from third parties through proxy bridges. If a third-party XML stream is manipulated by an attacker, the attacker can insert malicious content. The small XML parser within the browser processes this stream, and this XML parser may be vulnerable to XML Bombs. Additionally, further XSS script injection is possible. The use of XML that is not properly validated in the browser can have a malicious impact on end-users.

One-click bomb

A Web 2.0 application instance itself might be safe initially, but it can be vulnerable to injection attacks triggered when an event occurs. The onclick attribute, which triggers an action with a click, carries the risk of malicious links being inserted via JavaScript injection attacks. For example, a browser sitting on a “bomb” (a malicious code bomb) waits for a normal event from the end-user to trigger an explosion. If a specific event occurs by clicking a link or button, the exploit is successful. This can lead to session hijacking through malicious code. Such vulnerable elements expose the flow of information from untrusted sources without proper validation. To exploit these vulnerabilities, it is necessary to induce an event from the end-user. While these events may appear harmless, they can be extremely dangerous.

DOM Injection

The DOM (Document Object Model) is an object-oriented model that represents structured documents. It serves as a means to dynamically access and change the content, structure, and style of a document through scripts. Since APIs allow the programmatic modification of the DOM via JavaScript, exposure to XSS attacks can occur when the following JavaScript objects are utilized:

  • Raw HTML
    • document.write(…)
    • document.writeln(…)
    • document.body.innerHtml=…
  • Directly modifying the DOM (including DHTML events)
    • document.forms[0].action=…
    • document.attachEvent(…)
    • document.create…(…)
    • document.execCommand(…)
    • document.body. …
    • window.attachEvent(…)
  • Replacing the document URL
    • document.location=…
    • document.location.hostname=…
    • document.location.replace(…)
    • document.location.assign(…)
    • document.URL=…
    • window.navigate(…)
  • Opening/modifying a window, e.g.:
    • document.open(…)
    • window.open(…)
    • window.location.href=…
  • Directly executing script, e.g.:
    • eval(…)
    • window.execScript(…)
    • window.setInterval(…)
    • window.setTimeout(…)

To mitigate these risks, validation must be performed on client-side JavaScript objects used to access the DOM. Furthermore, on the Server-Side, special characters in user input that possess specific functional meanings should be filtered to restrict the insertion of malicious scripts.

Filtering should be applied to allow only permitted characters as follows:

Vulnerable Source Example

<SCRIPT>
Var pos=document.URL.indexOf(“name=”)+5;
Document.write(document.URL.substring(pos.document.URL.length));
</SCRIPT>

Secure Source Example

<SCRIPT>
  var pos=document.URL.indexOf("name=")+5;
  var name=document.URL.substring(pos,document.URL.length);
  if (name.match(/^[a-zA-Z0-9]*$/))
  {
      document.write(name);
  }
  else
  {
      window.alert("Security error");
  }
  </SCRIPT>
(2) Security Countermeasures

XSS is one of the most common attacks utilized by attackers to surreptitiously infiltrate web applications. Since XSS is an attack carried out through JavaScript, it can be fatal to Ajax, which is inherently built on JavaScript. When malicious scripts are inserted during the asynchronous loading of a web page, the nature of Ajax allows the attack code to execute on the user’s system without the user realizing they are being targeted. Furthermore, the fact that Ajax continues to trust a site once it has been established as trusted allows it to potentially bypass firewalls, which is a significant security concern.

Ultimately, because malicious users can exploit Ajax XSS vulnerabilities to steal user sessions, cookies, passwords, and sensitive personal information, the following countermeasures are recommended:

  • Server-Side Input Validation: Validation of input values must occur on the server side.
  • nput Processing Modules: Use dedicated modules to filter and prevent the insertion of abnormal malicious scripts.
    1. User Account & Password
      To block SQL Injection in authentication, define allowed lengths for numbers and uppercase/lowercase letters; do not accept other characters.
    2. Bulletin Board
      Control by defining the type (uppercase/lowercase) and length of input characters. Be cautious of strings used in CSS.
    3. ID Number (Resident Reg.)
      Define a numeric format of 6–7 digits for receiving resident registration numbers.
    4. Date Type
      Use predefined date formats or write expressions that match the date format.
    5. Numeric Type
      For bank transfers, ensure only positive values (+) are accepted to prevent balance manipulation via negative numbers.
    6. Special Characters
      Convert characters such as < > \ ” ‘ ( ) & into their respective entities for security.
FromTo
<&lt;
>&gt;
(&#40;
)&#41;
#&#35;
&&#38;
Anti XSS Ajax

Many web developers state that XSS remains a persistent problem. Because it is difficult to validate every single line of code that outputs user input, the application of even a few vulnerable attack methods can make defense nearly impossible. As we know, perfect code does not exist, and some bugs inevitably bypass inspection statements—especially if the reviewer lacks a security mindset.

To mitigate XSS risks in a real-world product environment, we must consider the following:

  • XSS attacks primarily occur on the user side.
  • XSS attacks are usually triggered using JavaScript.

From these perspectives, we conclude that we must block attacks on the client side to stop XSS that bypasses server-side defenses. Since XSS relies on <script> tags, we use JavaScript to filter the HTML passed from the server side. This serves to identify attacker scripts and notify both users and administrators.

The challenge lies in distinguishing malicious JavaScript from legitimate scripts. We can verify if a script is malicious by applying a “signature” to legitimate JavaScript. For example, a rand() function can be used to generate random values for all legitimate JavaScript, allowing us to sign it and distinguish it from unsigned malicious scripts.

<?
$file = fopen("log.txt","a");
$timestamp = date("D dS M,Y h:i a");
fwrite($file, "$timestamp\n");
fwrite($file, "$attackscript\n--------------------\n");
fclose($file);
?>

Malicious script contents can be logged, allowing site administrators to analyze the attack later. The log file is as follows:

--------------------
Fri 20th Jul,2007 12:38 am
alert(\"evil code\")
--------------------
Fri 20th Jul,2007 12:41 am
alert(\"more evil code\")
--------------------

In addition, we can leave more important information in the referral URL of the link the user followed. This allows us to determine how the attacker carried out the attack via email or other methods, record usernames, contact them to request assistance, or gain further information about the attack.

By using Ajax coding techniques, it is possible to warn users or operators in advance. This makes it more difficult for attackers to test for XSS vulnerabilities in the application without being noticed.

However, this technique leaves a significant challenge: warnings are only issued after an incident has occurred and the user has already suffered damage. This is due to the nature of JavaScript as a sequential language that is read line-by-line by the browser from the web server. Consequently, it cannot parse scripts that have not yet been read. One could use the sequential nature of the language to make the page wait during loading or introduce a delay of several milliseconds for each part. However, it is difficult to accurately identify when a malicious script has been loaded and perform actions before it executes.

If JavaScript supported a sleep() function, it would be an excellent solution. However, JavaScript does not support a sleep function.

Another solution is to request HTML content using the XMLHttpRequest object for a complete Ajax web page and update the page with a new link containing validation JavaScript every time a user clicks. However, this process would impose a significant load.

B. SQL Injection in Ajax

Typical web applications parse the result data on the server in response to a client’s query request and output the results in the HTML that the user sees. However, Ajax applications are sometimes designed to return the results of raw data from the server to the client, which then analyzes the received raw data and transforms it into HTML.

From a performance perspective, this approach is quite effective. Since data transformation routines take time, processing them on the client side can result in improved speed. However, there are potential security issues. Because the server sends raw results to the client, it allows for various forms of injection attacks against the query command logic. Instead of performing thousands of true/false queries, an attacker can simply request and receive the data itself. Usually, all data stored in the backend can be extracted with just one or two request statements. Since the number of requests is small, the likelihood of detection by security devices such as an IDS (Intrusion Detection System) decreases, which ultimately increases the probability of a successful attack.