Securing Web Applications before deployment.

An analysis focused on various framework used to deploy web

applications.

- By Shritam Bhowmick

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: ASP.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.

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 there

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:

1.) Configuration mismatch.

2.) Incompletion of source code and execution. (total deployment of the web application, even though

incomplete.)

3.) Presence of external sources (such as plugins, javascripts, and other resources).

4.) Presence of backup files on the server with directory listing enabled.

5.) Bad interpretation of HTTP flags, .httaccess file, and bad server configuration.

The Possibility of Stored XSS 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 or Java 4 does as per the analysis.

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 attacks:

https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

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 on Web Application deployed without any precautionary measures:

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 it's remedies regarding XSS:

https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet

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.

Possibility of SQL Injection on web application with precautionary measures taken:

According to the tests conducted, PHP 7 and Perl 5 were prone to SQL Injection attacks, provided the

web application was deployed without ay 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 Bypass on web application deployed without precautionary measures:

Test's 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:

1.) CSRF- Cross Site Request Forgery.

2.) Session Management- False Impersonation of session cookies.

3.) 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).

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 via ORM's.

Vulnerability Highlights on ASP.net Web Application deployment:

1.) ASP.Net padding oracle vulnerability.

2.) ASP.Net ViewState vulnerability.

3.) ASP.Net Forms "Authentication Bypass".

4.) ASP.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:

a.) When a valid Ciphertext is received by the application with valid padding and legit data.

b.) When an invalid Ciphertext is received by the application containing improper padding.

c.) 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:

1.) against a valid ciphertext on "WebResource.axd".

2.) against an invalid ciphertext.

3.) 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: jzjghMVYzFihd9Uhe_arpA2

http://website.com/application/WebResource.axd?d=jzjghMVYzFihd9Uhe_arpA2

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.