Client and Server Side Threats in Era of Web 2.0/HTML5

Client Side Software Threats

In the beginning of the evolution client side components were very thin and they were designed to render simple HTML pages but over years demand for better interaction started to drive browser development. In current state browsers are running with thick JavaScript engine, Ajax support, Flash & Silverlight plugins etc. At the same time heavy demand for cross domain interaction of application is required as well and cocktail of rich client running with cross domain access is perfect mix for next generation attacks targeted to end user’s identity. Here is a list of few evolving threats and risks.
 Cross Site Scripting (XSS) & Cross Site Request Forgery (CSRF)  - Cross site scripting is one of the dangerous attack vectors for traditional as well as Web 2.0 applications. An attacker can inject a malicious script at the browser end and its execution can compromise the client’s identity. We have already witnessed several different worms and viruses leveraging XSS to exploit browsers and application layer.
CSRF is another client side attacking vector, if application running on server side accepts incoming request without checking HTTP referrer or its intent then it is possible for an attacker to force browser to generate HTTP request without end client’s consent. This attack vector can prove lethal and end up compromising end user’s identity.
 Cross domain attacks & client side controls - Browsers are not supporting cross domain calls from Ajax as such. At the same time there are various cross domain calls are blocked in the browser security model which is based on same origin policies (SOP). But in this new application era where Web Services are emerging as driving force lot of applications are providing callback mechanisms for their services. Malicious code execution in the browser in this cross domain framework can lead to security crisis in browser security model.
Thick browser side components are using various different security controls to guard application layer. These client side components are designed to protect browser for malicious attacks or validating outgoing content from browser to web server. These controls can be bypassed by well-crafted attacks and bypassing validations can lead to expansion of attack surface.
De-compilation attacks & Framework issues – Applications may be using some of the components which can be decompiled like Flash, ActiveX, Applet or Ajax Scripts. An attacker can decompile the code and obtain internal information. This de-compilation process can lead to sensitive information and logic.
There are several different frameworks and toolkit out there which are providing extra support for applications for Ajax and Flash. These frameworks are having their own security concerns and issues. Framework running with publicly known vulnerabilities can make application insecure and these holes can be leveraged by attackers. Ajax frameworks like Dojo, Prototype, GWT etc. are few examples. Some of these frameworks are loaded on both client and server ends and vulnerability can lead to severe impact on application.
These are few important issues on client side. There are some other interesting areas like business logic disclosure, HTTP response splitting, local privacy issues, Intranet scanning, DOM content stealing, Widget injections, state bypass with Ajax, secret disclosure and DNS pinning. Above threats can compromise client side of components and access to browser’s sensitive information. At the same time we are seeing rise on server side of vectors as well.

Server Side Software Threats

Over the evolution, there are several new technologies and components are added on application or web servers along with technologies and user defined code. Poorly written source code or misconfigured deployment environment opens up several security aspects on security. It is interesting to see that these opening are not just compromising the application only but can create hazard for entire network. Following are some higher level threats.
Traditional application resources – Application resources like Active Server Pages or Java Server pages can be one of the powerful attack points with both traditional as well as Web 2.0 applications sine these resources may contain vulnerability. These traditional pages can be programmed in such a way that they can support various different structures like Name-Value pairs, JSON or XML. Hence, it is possible to manipulate name-value pairs and various other structures to locate possible vulnerabilities.
Web Services resources or SOA components – Web 2.0 application contain Web Services running on the server to support various XML driven services like SOAP, REST or XML-RPC. These resources are very separate and with specific entry points. These resources are one of the targets for abuse and one can launch set of attacks against them.
Networked resources – Next generation applications are running with Internet as platform so one application is linked with another application with bridge. An attacker can identify this bridge and launch attack through another site to abuse functionality. Since bridge is trusted it may be running with lower security controls and can be compromised easily.
Here is the list of server side application attack vectors in various groups;
Authentication - Bruteforce and Authentication logic
Authorization – Predictable, Client side exposure, Extra header injections and Secret paths
Malicious payload injections - SQL injections, LDAP injections, XPATH injections, OS command injection, File system access injection, large buffer injection and Integer overflow
 Application layer logic hacks - Denial of Services, Uploading content, Client side code exposure
 Session based attacks - Sniffing, Session cleaning and Predictable session.
Confidential information leakage - WSDL leaks, Error leaks, Directory indexing, Backup files, Ajax errors, DHTML code, XML-RPC forcing, SOAP faults
 Logging and Auditing – DoS, Logging bypass, Poor auditing
Next generation applications will need better security against new technologies and associated threats. We have seen evolution and possible threats in this blog entry, this is just a scratch on the surface. Attackers are evolving their techniques and exploiting whatever little opening they get on the surface. Objective for us is to how we can protect our applications against it.

XSS & CSRF with HTML5 - Attack, Exploit and Defense

HTML5 has empowered browser with a number of new features and functionalities. Browsers with this new architecture include features like XMLHttpRequest Object (L2), Local Storage, File System APIs, WebSQL, WebSocket, File APIs and many more. The browser is emerging as a platform like a little operating system and expanded its attack surface significantly. Applications developed in this new architecture are exposed to an interesting set of vulnerabilities and exploits. Both traditional vulnerabilities like CSRF and XSS can be exploited in this new HTML5 architecture. In this talk we will cover following new attack vectors and variants of XSS and CSRF.

HTML5 driven CSRF with XMLHttpRequest (Level 2)
CSRF with two way attack stream
Cross Site Response Extraction attacks using CSRF
Cross Origing Resource Sharing (CORS) policy hacking and CSRF injections
DOM based XSS with HTML5 applications
Exploiting HTML5 tags, attributes and events
DOM variable extraction with XSS
Exploiting Storage, File System and WebSQL with HTML5 XSS
Layered XSS and making it sticky with HTML5 based iframe sandbox
Jacking with HTML5 tags and features

In this session we will cover new methodology and tools along with some real life cases and demonstration. At the end we will cover some interesting defense methodologies to secure your HTML5 applications. My slides are as under (I will post video once get released)


[Case Study] Security Review of ACME's Marketplace Applications

Background
ACME is a prominent player in the Customer Relationship Management (CRM) industry, renowned for its robust cloud-based platform. This platform is equipped with a variety of built-in features, including leads, orders, contacts, accounts, and user management capabilities. Designed to meet diverse customer needs, ACME’s platform allows users and vendors to extend functionalities through a proprietary programming language. This flexibility enables the development of custom solutions that can be deployed on ACME's Marketplace, fostering innovation and user engagement.

However, the very features that provide flexibility and customization also introduce significant security vulnerabilities. As applications developed on the platform operate within the same environment as built-in features, insecure applications can jeopardize the entire system, exposing users to various risks and potentially damaging ACME's reputation. Thus, it becomes extremely important for the ACME to protect their platform itself as well as the data of users whenever users use the Marketplace apps developed by a third party.

Challenges

Security Risks: The ability for users and vendors to create custom applications raised concerns about the security of these applications, as vulnerabilities could be exploited to compromise the entire platform.

Inefficient Security Review Process: The existing security review process was time-consuming, particularly due to the limited coverage of automated Static Application Security Testing (SAST) scanners for the custom programming language used on the platform.

Manual Review Limitations: Conducting thorough manual reviews was essential but resource-intensive, leading to delays in application deployment.

Solutions
To address these challenges, ACME partnered with Blueinfy to develop a comprehensive security review strategy. The approach included several key components:

Tailored Security Review Process:
Blueinfy's experts conducted an in-depth analysis of ACME's platform, focusing on its built-in features and the unique programming language.

Checklist and Automation: A checklist of insecure coding practices was created, specifically tailored to the platform's programming language. Blueinfy developed specialized utilities to detect insecure coding patterns within the applications, enhancing the efficiency of the review process. This checklist and utilities served as a foundational tool for identifying vulnerabilities in custom code.

Focused Manual Code Reviews: The team performed manual code reviews, concentrating on the identified insecure patterns, while also addressing false positives and negatives to ensure accuracy.

Blackbox Testing:
External endpoints were identified from the code, and manual blackbox testing was conducted on these endpoints to further validate security.


Outcome
The implementation of this systematic security review process yielded significant improvements for ACME:

Enhanced Security: The comprehensive review process allowed for the early identification of vulnerabilities, thereby strengthening the overall security of the platform and its applications.

Reduced Review Time: By streamlining the security review process, ACME was able to validate applications more efficiently, significantly reducing the time required for comprehensive security assessments.

Conclusion
By implementing these strategies, ACME not only fortified its platform against potential threats but also established a model for ongoing security improvement in the rapidly evolving landscape of cloud-based applications.

Article by Amish Shah

File System API with HTML5 – Juice for XSS


HTML5 has come up with several APIs and one of them is File System API (http://www.w3.org/TR/file-system-api/). Browsers are implementing it and it is covering both directories and files under this API. Hence, now web application can create a mini file system and dump files inside the browser. These files can be accessed at any point in time by the browser with the same domain context. These files can be permanent or temporary. The browser is acting like a mini OS and exposing the surface. If XSS is found it is easy to extract full file system created by the application.

For example, if an application has created a token file on the file system using the API. We can see files by following URI on chrome.













In above figure we can see files are being created in the browser. Now assuming XSS is found, it is easy to exploit by hooking into the file system and extracting the content. Following code can be part of the access routine.
























Bottom-line, lot is getting added to HTML5 and strong JavaScript analysis and look around would be needed from security professional. Looks like developer community is still playing around with these APIs but the days are not far where we will start seeing these types of application in production and landing for review at the door steps. 

[Blackhat 2012] HTML5 Top 10 Threats Stealth Attacks and Silent Exploits

BlackHat 2012 was really fun and lots of interesting talks. I presented paper on HTML5 Top 10 Threats and Security. You can find slides and paper over here.




CSRF with upload – XHR-L2, HTML5 and Cookie replay


XHR level 2 calls embedded in HTML5 browser can open a cross domain socket and deliver HTTP request. Cross Domain call needs to abide by CORS. Browser will generate preflight requests to check policy and based on that will allow cookie replay. Interestingly, multi-part/form-data request will go through without preflight check and “withCredentials” allows cookie replay. This can be exploited to upload business logic files via CSRF if server is not validating token/captcha. Business applications are allowing to upload files like orders, invoices, imports, contacts etc. These critical functionalities can be exploited in the case of poor programming.

If we have a business functionalities for actual upload form then this type of HTTP request will get generated at the time of upload. Note, cookie is being replayed and request is multi-part form.

Now, if CSRF payload has following XHR call.



Above call will generate following HTTP request and causes CSRF and upload the file. Hence, without user’s conscent or knowledge cross domain file being uploaded on the target application with the logged in credential.



Future probes – one needs to check other impact like AMF stream uploading, XML file transfer and few other library protocols which is now a day’s dealing in multi-part to support binary calls.

If you are interested in this analysis should visit @kkotowicz work - http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html.