Securing Web Applications before Deployment.
An analysis focused on various framework used to deploy web applications.
By Shritam Bhowmick Web Application Penetration Tester LinkedIn: https://www.linkedin.com/profile/view?id=281014248&trk=nav_responsive_tab_profile Academia: https://independent.academia.edu/ShritamBhowmick Facebook: https://www.facebook.com/coded32
Dedicated vulnerability and bug researchers go deep into the application security aspects while studying application internals and there is a prominent rise in hidden attack vectors which are never common. There is a default common misconception among the developers that deploying applications which are vendor-enabled with 3rd party proprietary framework libraries will add security to the application. Libraries which the developers rely on are themselves vulnerable if properly dissected and studied. This brings business concerns to the business assets. The business assets could be anything from bank details to storing credit card information for customers to easily access such numbers for the ease of the customers. Although data integrity is maintained when storing and is encrypted, it takes a while for an attacker to get in and get out without being really noticed. Contrary to the statements above, there is yet another belief that Open source libraries will be safer since they go revisions by the mass community but the truth is bitter. Again, deep down in the open-source libraries, there exist multiple critical vulnerabilities which needs to be addressed before deploying them as they are. The information given below will detail the vulnerabilities which are deep inside the libraries which are used to deploy rich internet based applications.
What Developers see as a convenient way for deploying a web application?
- Languages used: PHP, JAVA, Ruby, SCALA, Perl, Python, HASKELL, Cold Fusion and more.
- Framework Used:NET, Zend, CodeIgniter, Spring, Catalyst, Snap, CakePHP, Yii, Fusebox, and more. Even more popular ones are Django, Sinatra, Mason, Pyjamas, Symfony and Grails.
QnA on ASP.net Vulnerabilities: http://forums.asp.net/1233.aspx
Vulnerabilities Reflected to CodeIgniter: http://www.cvedetails.com/vulnerability-list/vendor_id-6918/Codeigniter.html
EL Injections (Expression Language Injection) which leverages to RCE on Spring Framework -> http://www.infosecurity-magazine.com/view/30282/remote-code-vulnerability-in-spring-framework-for-java/
Known CakePHP vulnerabilities: http://www.cvedetails.com/vulnerability-list/vendor_id-11278/product_id-20394/Cakefoundation-Cakephp.html
The Possibility of all total Vulnerabilities without precautionary measures:
Manual tests reveals certain heights of results in the presence of web application vulnerabilities. And these vulnerabilities are fatal for any business asset. Black-box tests reveals fewer vulnerabilities, provided source code and different access was not been given by the client. Also, in addition, taking into account the known set of attack vectors and their impact on the web application depends on the source code in place and how in addition to the framework, the concerned web application has been deployed. Certain symptoms like:
- Configuration mismatch.
- In-completion of source code and execution. (Total deployment of the web application, even though incomplete.)
- Presence of backup files on the server with directory listing enabled.
- Bad interpretation of HTTP flags, .httaccess file, and bad server configuration.
The Possibility of Stored XSS (Cross Site Scripting) deep down the web application:
PHP 8 and Perl 5 are most affected. Tests conducted by the test team is “manual”.
Java 9 suffers Stored XSS. Neither Java 3 nor Java 4 does as per the analysis of the results obtained from the vulnerability assessment tests. Hence the best deployment would be Perl 2, considering, other mix collations of perl with other source application code would lead to different attack vectors (if at all deployed!).
Mitigation for XSS (Cross Site Scripting) attacks
Stored XSS does not need a malicious link to be exploited. A successful exploitation occurs when a user visits a page with a stored XSS. The following phases relate to a typical stored XSS attack scenario:
- Attacker stores malicious code into the vulnerable page
- User authenticates in the application
- User visits vulnerable page
- Malicious code is executed by the user’s browser
Possibility of Reflected XSS (Cross Site Scripting) on Web Application deployed without any precautionary measures could be witnessed in the following statistical graph:
A series of multiple “manual” as well as “black-box” test shows PHP 6 and Perl 5 suffers from Reflected XSS when web application is deployed without testing. (Without going through a penetration test). OWASP project discuss the prevention of XSS attacks and its remedies regarding XSS:
Most serious XSS attacks are turned towards a site’s customer (or the web admin) to infect him/her with malicious browser scripts (also XSS worms: http://en.wikipedia.org/wiki/XSS_worm). This infection, would either lead to compromise of browser session cookies, which would then be used to impersonate a legit user, with that of an attacker and gain full access of the site (if a web admin) or else “could” also lead to full operating system compromise (if browser is vulnerable) of the victim in place.
Possibilities of SQL Injection
Possibility of SQL Injection on web application with precautionary measures taken could be witnessed from the below statistical graph:
According to the tests conducted, PHP 7 and Perl 5 were prone to SQL Injection attacks, provided the web application was deployed without any IT security audit as precautionary measures, remediation and mitigation. Leveraging SQLi attacks would ultimately lead to database compromise, and hence compromising the whole application, integrity and the reputation of the web application deployed.
Possibilities of Authentication and Authorization Bypass
Possibilities of Authentication Bypass on web application deployed without precautionary measures:
Tests on Authentication bypass shows Java 4, Java 9 PHP 6 and Perl 5 were most vulnerable when deployed to web application without any penetration test conducted.
Binary Vulnerabilities on ORM deployments and in-general .NET applications:
- CSRF- Cross Site Request Forgery.
- Session Management- False Impersonation of session cookies.
- Password Storage- Default password storage, backup files, Misconfiguration, and web application configuration files leakage.
The implementation of attack vectors (CSRF and Session Management) are itself taken care by the framework used (Most of the framework, 95% of all total framework, either by default or via the manual settings that has to be turned ‘ON’ by the developer himself).
Framework Driven Application Attacks
The following graphs shows the different aspects on implementation of “certain’ attack vectors that are limited to ORM deployments of web application with contrast to black-box penetration testing methodology as well as manual (OWASP standards and SANS) testing.
The following graph shows the “automation” process of finding vulnerabilities in the web application deployment ORM’s.
Vulnerability Highlights on ASP.net Web Application deployment:
- Net padding oracle vulnerability.
- Net ViewState vulnerability.
- Net Forms “Authentication Bypass”.
- Net HashDoS “attack”.
ASP.Net Padding Oracle Vulnerability and Remediation:
An application is vulnerable to Padding Oracle attacks, if it responds (HTTP server status code) differently to the following circumstances:
- When a valid Ciphertext is received by the application with valid padding and legit data.
- When an invalid Ciphertext is received by the application containing improper padding.
- When a valid Ciphertext is received by the application, which is properly padded, but when the Ciphertext is decoded at the application level, it’s invalid for the application to understand the decoded Ciphertext, hence failing to process the received Ciphertext.
Crafted tool to verify remote attacks to an application (which is applicable to Padding Oracle Vulnerability) could be fetched from https://github.com/GDSSecurity/PadBuster for study and verifying if the application is vulnerable. This tool is debugged as “PadBuster”. The concept of padding mismatch occurs when ciphertext requires specific blocks of data which fits to its cryptographic padding mechanism rather than an un-crafted plain text which isn’t properly crafted and sent to the vulnerable web application in “certain” ways. To fulfill the design requirements of the cryptographic padding, the application has to be deployed in such a way, as to accept the un-crafted, un-validated, and plain text inputs such a way in which the padding occurs automatically and distributes the received cipher in exact blocks.
The file vulnerable to Padding Oracle attack is “WebResource.axd”. The same exact file is used in Padding Oracle Exploitation, is because this particular file responds in different ways (different responses) when conditioned to the circumstances before. The 3 different conditions to which the “WebResource.axd” file is tested were:
- Against a valid ciphertext on “WebResource.axd”.
- Against an invalid ciphertext.
- Against a valid ciphertext which was properly padded but when decoded, the application would not understand the ciphertext.
A.) Valid Ciphertext.
When a valid ciphertext is supplied to the “WebResource.axd” file, the response status code is “200”, which is “OK” and the response body contains the resources requested.
The Original padded ciphertext:
Where the parameter is “d” with “?d=” which intakes the padded ciphertext.
B.) Invalid Ciphertext.
When an invalid ciphertext is issued to the file “WebResource.axd”, with the intake parameter as “?d=” (which might be different in other cases), an internal server error with a status code of “500” was responded back. We see these response code via ay HTTP header debugger or LiveHTTPS (an firefox browser addon). On performing an invalid padded ciphertext on the file “WebResource.axd”, we get “Internal Server Error” which has a status code ‘500’.
This shows, how differently the “WebResource.axd” file responded differently to valid ciphertext and invalid ciphertext which was not “padded”, and was a random character string.
C.) Valid ciphertext but invalid data.
When an valid ciphertext with no data (or invalid data) is issued to the file “WebResource.axd”, with the intake parameter as “?d=”, a response status code of “404” (Not found) is thrown back, with the body containing an error message.
This is the Padding Oracle Vulnerability. When an application responses back differently to different conditions, the web application lies vulnerable to the padding oracle attack. This attack could also extend to decaptcha a valid captcha, manipulate it and foreplay the captcha if the application uses captha for its security integrity (which is a rare case). In general, this vulnerability is exploited to achieve the Web.config file remotely and get access to the remote databases, provided the credentials were stored in the Web.config file.
Unlike any other common parameter based application vulnerabilities, the vulnerabilities which I just mentioned are found beyond the surface application layer and may get exploited with combination of network and application layers. It’s deep vulnerability research which makes the security a far more diverse field to what it has become now. There is mobile applications, rich internet applications (RIA), blended attacks on the web-server, skillful deduction of low-level attacks which gets to exploit the high-level, a combination of both low to high level attacks and a handful of twisted attacks from low hanging application vulnerabilities which are thought to be a low risk and could be exploited to gain a higher attack surface compromising every business asset on their way. The In-depth of study of these variants of attacks are beyond the thinking of any normal methodology based test and hence rely purely on the skills of an attacker or the penetration tester.
There are ways which could go un-noticed by system or web administrator and hence practically logs seems to be normal. This is an absolute deception point such as malware driven application attacks, honeypot driven application attacks and most of these attacks violates the human weak link since they are the most vulnerable. Some of the professional penetration testers believe they should stick to a checklist which should be followed since application security in itself has a vast scope coverage and is not possible for a pen-tester to go through every detail in-depth. Still applications at a raw stage is considered to be (or, rather assumed to be) having application level bugs which is the reason why so many bug bounty programs have now appeared.
Research and Development
I have had worked with various application security industries and by far now found Defencely to be the top notch at its play. Boasting expert application security researchers under their hood, the applications are first dissected in particular order according to the scope and then if source code is available, each module goes unit testing for security. This way a pure white-box approach could take this level of in-depth discussed earlier to the greatest heights possible and possibly the only known way. Lexical analysis and many other similar ways are performed at the Labs to provide security to its best fit for the clients and deliver application security reports.
The R&D is the only sector which provides and discovers amazing product platform for any concerned businessmen in the leading web-retail, e-commerce, medical, or business related corporate industries. It’s a boon for the security, as well as takes considerable time to keep relying on various equipment and the team. This brings one to the topic, why it is essential for a R&D team at the office. The key aspects to research is that it provides:
- Information Update on the go
- New emerging testbed vulnerabilities
- New application attack vectors for the company
- Sound knowledge of the security researchers keeps being updated
- More clients stay happy and never leave since they know the best fit
Investment to R&D is surely an asset to the company and this has been proved. There is no re-inventing the wheel and new attack vectors could be discovered which then could be used to deliver high-hanging fruits for the beneficiary of both the company and the client. This does not only earn respect but value among other security industries. Defencely has been playing an important role at R&D wherein application security experts break applications to the deepest layers as is possible. They methodological approach to breaking depends on what ways these application have been dissected as. There are other various ways which could take a book, but the key ingredients to success of Defencely has been its research team, its deliverance and the huge industry trust it has gained around the globe. The elite expert team has made it seamlessly possible for the clients to now have a total productivity time for their development instead looking out for security holes and web-server misconfigurations which could be used by an attacker to compromise the underlying applications hosted. Business logic threats are another story all over and Defencely takes cares of every possible ways it could relate to using its own security testing methodologies and key research experts. Security research is vastly becoming an essential asset and is found to be playing an important national role in securing personal, financial and corporate information. Blended beautifully, application security is now a global concern and for it to take the next leap, research and development has been the key.
About the Author
Shritam Bhowmick is an application penetration tester professionally equipped with traditional as well as professional application penetration test experience adding value to Defencely Inc. Red Team and currently holds Technical Expertise at application threat reporting and coordination for Defencely Inc.’s global clients. At his belt of accomplishments, he has experience in identifying critical application vulnerabilities and add value to Defencely Inc. with his research work. The R&D sector towards application security is growing green at Defencely and is taken care by him. Professionally, he have had experiences with several other companies working on critical application penetration test engagement, leading the Red Team and also holds experience training curious students at his leisure time. The application security guy!
Shritam Bhowmick has been delivering numerous research papers which are mostly application security centric and loves to go beyond in the details. This approach has taken him into innovating stuff rather than re-inventing the wheel for others to harness old security concepts. In his spare time, which is barely a little; he blogs, brain-storms on web security concepts and prefers to stay away from the normal living. Apart from his professional living, he finds bliss in reading books, playing chess, philanthropy, and basket-ball for the sweat. He wildly loves watching horror movies for the thrill.