Top 10 Ajax security vulnerabilities and their causes

JavaScript Ajax is an important component of Web applications. The evolution of this Part has turned the network into a super platform. The transformation also gave birth to new varieties of viruses and worms, such as Yamanner, Samy, and Spaceflash. Portals such as Google, Netflix, Yahoo, and MySpace have suffered some losses over the past few months due to new vulnerabilities. Hackers can exploit these vulnerabilities for phishing, cross-site scripting (XSS), cross-site forgery (XSRF) requests, and other attacks.

Ajax does not have inherent security vulnerabilities, but the adaptation to this technical vector significantly changes the development approaches and methodology of network applications. In the past, it was very difficult to serialize data and objects when DCOM and CORBA formed the core middleware layer. Ajax uses simple GET, POST, or SOAP calls to convert XML, HTML, JS Array, JSON, JS Objects, and other custom Objects. All these operations do not need to call the middleware layer. This comprehensive ability of Ajax makes the data exchange between the application server and the browser very smooth. Information sent from the server is dynamically injected into the current DOM-related environment, and the browser's DOM status is reset. Before talking about security vulnerabilities, let's take a look at the key factors that contribute to the Web vulnerability.

Multiple scattered terminal points and hidden calls-the main difference between web applications and Web1.0 is the difference between information access mechanisms. Compared with its predecessor Web1.0, Web2.0 applications have several Ajax endpoints. Potential Ajax calls are distributed across the entire browser page and can be called separately by various events. It is difficult for developers to cope with the dispersion of Ajax calls. Because these calls are hidden and not so obvious, they may also cause code irregularities.

Chaotic authentication-Authentication of input and output content is an important factor in applications. Web applications use bridges, mashups, and feedback. In many cases, it assumes that the "other party" reads the server or client code) has implemented authentication, which leads to the failure of both parties to implement proper authentication control.

Untrusted sources of information-Web applications obtain information from many untrusted sources such as feedback, blogs, and search results. These contents have never been authenticated before they are provided to the terminal browser, which may lead to cross-site attacks. Hackers may also load JavaScript in the browser to force the browser to make cross-domain calls and open security vulnerabilities. In this way, these critical vulnerabilities can be exploited by viruses and worms.

Data serialization-the browser can call Ajax to implement data serialization. It can obtain JS array, Objects, Feeds, XML files, HTML blocks, and JSON. If one of these sequence blocks is parsed and modified, hackers can force the browser to execute malicious scripts. The combination of untrusted Information and Data serialization is critical to the security of end users.

Dynamic script composition and execution-Ajax will establish a backend channel, get data from the server, and then send it to DOM. To achieve this, you must dynamically execute JavaScripts to update the DOM or browser page cache status at any time. Ajax calls a custom function or eval () function. Unauthenticated content or insecure calls may lead to leakage of session content, which forces the browser to execute malicious content and other consequences.

Web applications may be vulnerable to attacks due to one or more mistakes mentioned above. If developers are not careful enough to focus on security management, security problems may occur on servers and browsers. The following is a brief description of 10 possible security vulnerabilities.

1) malformed JS Object Sequence

JavaScript supports Object-Oriented Programming (OOP) technology. It has many different built-in objects and allows users to create their own objects. You can use new object () or edit the following code to create a new object.

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

This is a simple message object. Two fields require an email address. We can use Ajax to serialize the object and compile it with JavaScript code. Programmers can assign values to variables or eval (). If attackers send malicious "Themes" embedded in scripts, the readers will become victims of cross-site scripting attacks. JS objects contain both data and methods. Improper use of JS object sequences will generate security vulnerabilities that can be exploited by complicated injection code.

(2) JSON Injection

JavaScript Object Notation (JSON) is a simple and effective small amount of data exchange format. It contains objects, arrays, Hash tables, vectors, and list data structures. JavaScript, Python, C, C ++, C #, and Perl versions support JSON. JSON sequence is an effective exchange mechanism in Web2.0 applications. Developers frequently use Ajax and JSON to obtain and transmit necessary information to DOM. The following is a simple JSON object with different name values: "bookmarks" object.

{"bookmarks":[{"Link":"www.example.com","Desc":"Interesting link"}]}

Hackers can inject malicious scripts into Link or Desc. If DOM and executable programs are injected, the XSS directory is also injected. This is another way to infect end users with malicious content.

(3) JS array poisoning

JS arrays are another common serialized object. People can easily port it across platforms, and it is also effective in the structure of different languages. Infecting a JS array can disrupt the entire DOM environment. Hackers can use simple cross-site scripting to attack the JS array in the browser. The following is an example of a JS array:

new Array(“Laptop”, “Thinkpad”, “T60”, “Used”, “900$”, “It is great and I have used it for 2 years”)

This array is uploaded from a website that auctioned second-hand laptops. If this array object is not carefully processed on the server side, hackers can inject scripts into the last field. Such injection threatens the security of the browser and is exploited by attackers.

(4) modified XML data streams

Ajax calls accept XML from multiple addresses. These XML blocks come from network services that run on SOAP, REST, or XML-RPC. These network services are received from a third-party proxy bridge. If these third-party XML data streams have been modified by attackers, attackers may inject malicious content into them.

The browser receives the data stream from its built-in XML parser. The parser is vulnerable to different XML bombs. People can also inject scripts into the data stream, which can lead to cross-site scripting (XSS) attacks ). If the browser receives unauthenticated XML data streams, the security of the client is compromised.

(5) Script Injection in DOM

The first four vulnerabilities are caused by serialization problems. Once the browser receives the serialized object data stream, the developer sends a call to access the DOM. The purpose of this call is to "Override" or "Refill" the new content into the DOM. You can call eval () or use document. write (). If these calls are performed on untrusted information flows, the browser may be attacked due to DOM operation vulnerabilities. Attackers can use many document. * () calls to inject XSS into the DOM environment.

For example, this JavaScript code: Document. write (product-review ).

Here, "Product-review" is a variable obtained from a third-party blog. What if it contains JavaScript? The answer is obvious. This JavaScript will be run by the browser.

6) Cross-origin access and callback

Ajax cannot be accessed from the browser cross-origin. All popular browsers have a security feature, that is, intercept cross-origin access. Some WebSite Services provide callback for object sequences. Developers can use this function to integrate website services into the browser itself. People can send this function name back, so that when the browser finds the callback object data stream, it will be executed by a special function name in the browser.

This callback is an extra burden for developers who use browser authentication. If the input object data stream is not authenticated by the browser, the terminal client will become the target of cross-origin attacks. Whether intentionally or unintentionally, the cross-origin service can inject malicious content into the browser. This cross-origin call runs in the current DOM environment, making the current conversation vulnerable. Before implementing the application, you need to carefully check the entire cross-origin function.

7) RSS and Atom Injection

Joint feedback, RSS, and Atom are the most common methods to transfer site update information to the network. Many News, blogs, and portals share multiple feedbacks on the Internet. Feedback is a standard XML document and can be received by any program. Web applications use widgets or internal browser components to integrate feedback. These components call Ajax to access feedback.

These feedback can be easily selected by end users. Once you select them, these feedback will be parsed and injected into the DOM. If this feedback is not properly authenticated before injection, some security problems may occur. Attackers can inject malicious links or JavaScript code into browsers. After the injection, it was very bad. The final result was that XSS and the conversation were intercepted by hackers.

8) Click the bomb

Web applications may not be easily attacked by hackers, but they can inject them based on events. Attackers can inject malicious links with the word "onclick" into JavaScript. In this way, the browser will bring a bomb that is triggered by right-clicking the terminal user at any time. Once the user clicks the link or button, the event that can start the bomb is started, the attack succeeds. Such attacks can cause malicious code blocking of conversations.

This is also a security vulnerability caused by information obtained from untrusted sources that have not been correctly verified. To exploit this security vulnerability, a terminal client needs to trigger an event. This event may be harmless, such as clicking a button or link, but clicking it causes heavy user losses. It may cause a malicious event, send the current conversation information to the target, or execute a series of script attacks in the current browser environment.

(9) Flash-based cross-origin access

Hackers can use the Ajax interface of the Flash plug-in to send GET and POST requests using JavaScritps in the browser. This interface allows hackers to make cross-origin calls. To avoid security issues, the Flash plug-in provides the ability to access other domains based on policies. This policy can be configured by placing the crossdomain. xml file at the root of the domain. If the file to be placed is improperly configured-a common phenomenon-it may allow cross-origin access. The following is an XML document with improper configuration:

Now you can make cross-origin calls from the browser itself. This structure also has some other security issues. If Flash-based rich network applications (RIA) are incorrectly configured, it is easy to be attacked due to Ajax cross-origin access bugs.

(10) XSRF

Cross-origin forgery (XSRF) is an old attack vector that forces the browser to send http get or POST requests to different domains; these requests can start an event in the running application logic across domains. It may request to change the password or email address. After the browser calls it, It replays the cookie and obtains identity authentication. This is the key part of the request. If an application identifies its identity only based on cookies, the attack succeeds.

Ajax in Web is a conversation between XML-RPC, SOAP or REST and backend network services, which can be called through GET and POST. In other words, people can call these network services across sites, endangering the identity information of victims and network service interfaces. The XSRF attack vector is very interesting. It creates a new level in the New Territories endpoint. These endpoints may be prepared for Ajax or web services, but they may also be activated by cross-origin requests.

Attacks against security vulnerabilities and Corresponding Countermeasures

Web applications have multiple terminal points. Each point is a threat intrusion point. To ensure security, we should protect all these points. Complete processing of third-party information before sending it to the client.

To process Ajax sequences, the input data streams must be verified before they reach the DOM. XML parsing and cross-domain security issues also require additional attention and better security management measures. We should follow the simplest and most clumsy principle: preventing unauthorized cross-origin information from entering the browser. Interestingly, so far, security experts have not advocated using client scripts for input verification because it is easy to avoid.

Web2.0 has contributed to many new browser security vulnerabilities. It is difficult but not impossible to exploit these security vulnerabilities. The combination of security issues and contributing factors will seriously affect those large network groups, such as those that can be exploited by attackers, worms, and viruses. This will eventually cause the leakage of identity information.

Conclusion

This article briefly describes some possible Ajax vulnerabilities. There are also many other potential vulnerabilities, such as the use of cross-origin proxy to create a single channel or store variables in the browser.

Many logics in Web2.0 are transferred to the client. This exposes the entire application to some serious threats. The urgent requirement for integrating data from multiple sources and not from the source will also comprehensively add risk vectors: XSS, XSRF, cross-domain issues, client sequences, and insecure WebSite Services, XML-RPC and REST access on the server side. On the contrary, Ajax can be used to construct beautiful seamless data integration. However, any insecure call or information flow will result in counterproductive results and lead to available security vulnerabilities.

These new technology vectors are promising and exciting, but attackers, viruses, and worms are more interested in them. To ensure security, developers should be especially careful about these details.