Ajax, HTML5 and mobile-based applications are bringing in some significant changes to next generation application architecture. Hence, it is important to understand HTML5 to get a better security perspective. HTML5 allows applications to run in a thick client environment, have its own file system, SQL database, local variable storage and socket within the browser framework. Whether this instance of the browser is a part of desktop or mobile is immaterial.
Traditional applications have clear layers like presentation, business and data access. Typically, only the presentation layer would run on the client side and the other components would exist on the server side. Hence, the business logic and data access are server side.
In an HTML5 application things can be coded differently. It can have its own powerful business and data access layers. Hence, the developer can migrate some of the server side components to the client side by leveraging these features. As shown in figure 1, the shaded corner rectangle is an overlap, this is the component, which runs on the client side in the browser or mobile (app) and executes within the client framework. This is a significant change; it allows applications to run in offline mode as well. At the same time, some of the server side implementations are now exposed to the client and some threats and security issues can emerge by tampering HTTP responses. HTML5 has a powerful presentation layer with newly added tags and markups. At the same time, mobile’s native applications written on iOS or Android are having great capabilities to host thick features on client side. It also encompasses an effective business layer by having strong APIs accessible by JavaScript or native (mobile) along with the data access layer.
Traditionally, penetration testing of the application is relying on the HTTP request fuzzing and tampering. Not much focus is given to changing and tampering HTTP response streams but things are now changed with modern and mobile architectures driven in API frameworks. With modern browser baked with HTML5 and powerful JavaScripts libraries, it is possible to do a lot more at client side as part of the browser as well as on mobile apps. Some key decision making parameters are coming from server as part of HTTP response and these can be tampered to discover vulnerabilities and get into different flow of application at the browser/mobile end.
Figure 1 - Hybrid layers of modern architecture both for web and mobile apps
In current context, JavaScript libraries are allowing to write business logic on client side. During our pen-testing and JavaScript reviews, there have been instances where the response modification and tampering opens up the new functionality on presentation side in complex JavaScripts running on browser or mobile ends. It is new keys to the kingdom and surprising in many cases. It allows attacker to do range of things form abusing functionalities to privilege escalations both on mobile and browser front. Following are some of the examples observed across browser as well as mobile applications, we are sure there are many other outcomes of this technique where focus is kept on HTTP response streams like JSON, XML, Flags etc.
a.) Privilege escalation and role change
Typically, the application would have multiple roles to deal with privileges and authentications. Based on the user role, the application design would serve different user interfaces to the browser and mobile layers. In this case, the application was setting a numeric value once user logs in to “3” for a normal user in the JSON call. User interface will take decision based on this value and build dynamic look over HTML5/mobile interfaces. If the value of the parameter is changed is set to “1”, the application ends up escalating role and now having access to a few more menu items both on web and mobile interfaces. These menus and access are designed for admin only. Hence, major breach is now possible since any user can escalate its role to the admin user as shown below.
b.) Abusing password functionality
There are certain applications which would have multiple steps on single page to offer change password functionality. In first step user gets a prompt to enter the old password. If the old password matches on the server side, the application redirects user to enter new password and if old password does not match, the application redirect user to enter old password again. This opens up a way to abuse HTTP responses, if attacker modifies the server response from FAIL to SUCCESS in first step, the application redirects user to enter the new password even though old password is incorrect. There is possibility to abuse this scenario as well.
c.) Unauthorized access to mobile screens on device
Many mobile applications are coming up with login screen at the start point and after authentication it sends large JSON stream back as response. Based on various parameters defined on the stream, application loads various pages from mobile device to the end users. This JSON stream coming from response can be polluted and poisoned by tampering values. Hence, application ends up providing set of support and escalated state of the user. Using these cards/pages, user can access various set of paid functionalities, which are not open for free users. This technique is very effective for mobile based applications.
d.) Enabling buttons using java script modification
For example, the application is having a view user profile functionality, which displays the user details including email address as userID with "Save" and "Cancel" buttons. As user has only view permission the "Save" button is disabled. By analyzing JavaScript, one can identify the disabled button. But by modifying the JavaScript in response or in-browser, it is possible to enable "Save" button and submit the record to the server. This allow us to see actual HTTP traffic build and generated by Ajax call as well. Now, it opens up new doors for HTTP request tampering as well.
Conclusion
In this blog write up we have covered four scenarios but there are many more we can identify in Single Page Applications and mobile apps, which are responsive in nature for web based applications. Both mobile and web based applications are leveraging HTML5 and JavaScript heavily along with customized response streams like JSON, XML, JS-Objects etc. Hence, in the era of modern and mobile applications it is not enough to fuzz request streams only, it is imperative to fuzz and tamper response streams as well. It is important to understand role and value of manual penetration testing over automated since automated tools are not using response tampering in usual cases.
Traditional applications have clear layers like presentation, business and data access. Typically, only the presentation layer would run on the client side and the other components would exist on the server side. Hence, the business logic and data access are server side.
In an HTML5 application things can be coded differently. It can have its own powerful business and data access layers. Hence, the developer can migrate some of the server side components to the client side by leveraging these features. As shown in figure 1, the shaded corner rectangle is an overlap, this is the component, which runs on the client side in the browser or mobile (app) and executes within the client framework. This is a significant change; it allows applications to run in offline mode as well. At the same time, some of the server side implementations are now exposed to the client and some threats and security issues can emerge by tampering HTTP responses. HTML5 has a powerful presentation layer with newly added tags and markups. At the same time, mobile’s native applications written on iOS or Android are having great capabilities to host thick features on client side. It also encompasses an effective business layer by having strong APIs accessible by JavaScript or native (mobile) along with the data access layer.
Traditionally, penetration testing of the application is relying on the HTTP request fuzzing and tampering. Not much focus is given to changing and tampering HTTP response streams but things are now changed with modern and mobile architectures driven in API frameworks. With modern browser baked with HTML5 and powerful JavaScripts libraries, it is possible to do a lot more at client side as part of the browser as well as on mobile apps. Some key decision making parameters are coming from server as part of HTTP response and these can be tampered to discover vulnerabilities and get into different flow of application at the browser/mobile end.
In current context, JavaScript libraries are allowing to write business logic on client side. During our pen-testing and JavaScript reviews, there have been instances where the response modification and tampering opens up the new functionality on presentation side in complex JavaScripts running on browser or mobile ends. It is new keys to the kingdom and surprising in many cases. It allows attacker to do range of things form abusing functionalities to privilege escalations both on mobile and browser front. Following are some of the examples observed across browser as well as mobile applications, we are sure there are many other outcomes of this technique where focus is kept on HTTP response streams like JSON, XML, Flags etc.
a.) Privilege escalation and role change
Typically, the application would have multiple roles to deal with privileges and authentications. Based on the user role, the application design would serve different user interfaces to the browser and mobile layers. In this case, the application was setting a numeric value once user logs in to “3” for a normal user in the JSON call. User interface will take decision based on this value and build dynamic look over HTML5/mobile interfaces. If the value of the parameter is changed is set to “1”, the application ends up escalating role and now having access to a few more menu items both on web and mobile interfaces. These menus and access are designed for admin only. Hence, major breach is now possible since any user can escalate its role to the admin user as shown below.
Figure 2 - Privilege escalation and role abuse
b.) Abusing password functionality
There are certain applications which would have multiple steps on single page to offer change password functionality. In first step user gets a prompt to enter the old password. If the old password matches on the server side, the application redirects user to enter new password and if old password does not match, the application redirect user to enter old password again. This opens up a way to abuse HTTP responses, if attacker modifies the server response from FAIL to SUCCESS in first step, the application redirects user to enter the new password even though old password is incorrect. There is possibility to abuse this scenario as well.
c.) Unauthorized access to mobile screens on device
Many mobile applications are coming up with login screen at the start point and after authentication it sends large JSON stream back as response. Based on various parameters defined on the stream, application loads various pages from mobile device to the end users. This JSON stream coming from response can be polluted and poisoned by tampering values. Hence, application ends up providing set of support and escalated state of the user. Using these cards/pages, user can access various set of paid functionalities, which are not open for free users. This technique is very effective for mobile based applications.
d.) Enabling buttons using java script modification
For example, the application is having a view user profile functionality, which displays the user details including email address as userID with "Save" and "Cancel" buttons. As user has only view permission the "Save" button is disabled. By analyzing JavaScript, one can identify the disabled button. But by modifying the JavaScript in response or in-browser, it is possible to enable "Save" button and submit the record to the server. This allow us to see actual HTTP traffic build and generated by Ajax call as well. Now, it opens up new doors for HTTP request tampering as well.
Conclusion
In this blog write up we have covered four scenarios but there are many more we can identify in Single Page Applications and mobile apps, which are responsive in nature for web based applications. Both mobile and web based applications are leveraging HTML5 and JavaScript heavily along with customized response streams like JSON, XML, JS-Objects etc. Hence, in the era of modern and mobile applications it is not enough to fuzz request streams only, it is imperative to fuzz and tamper response streams as well. It is important to understand role and value of manual penetration testing over automated since automated tools are not using response tampering in usual cases.
Article by Hemil Shah & Shreeraj Shah