Lab 5 Application Security

In this lab, we are focusing on security in web applications. We should be able to describe the flaw of web application and its exploitation, exploit web applicaion vulnerabilities, as well as explaining the prevention methods that can be taken to overcome web application vulnerabilities.
We have been introduced on the Open Web Application Security Project (OWASP), an open community focusing on improving the security of application software. Free materials are provided, such as articles on secure programming, security testing guide, and much more. So, join in the OWASP community at http://www.owasp.org
We have also being exposed with the usage of WebGoat and WebScarab. WebGoat is basically a simulation toolkit used to demonstrate how to exploit the vulnerabilities of a poorly designed web application. WebGoat is designed with the J2EE framework for convenience of users in understanding security issues by applying security knowledge they have into exploting a real vulnerability in WebGoat application.
Along with this simulation tool there is the WebScarab, a tool for anyone who needs to expose the workings of an HTTP(S) based application, whether to allow developers to debug application problems, or to allow a security specialist to identify vulnerabilities in such a way that the application has been designed or implemented.
In our first task, we did a hacking simulation using WebGoat and WebScarab.
For more information on how to use WebScarab and WebGoat
http://www.owasp.org/index.php/Category:OWASP_WebScarab_Project
and
http://yehg.net/lab/pr0js/training/webgoat.php

Cross-side scripting (XSS) is a type of computer security vulnerability typically found in web applications which enable malicious attackers to inject client-side script into webpages viewed by other users. An exploited XSS vulnerability can be used by hackers to bypass access controls.
Several steps in preventing XSS include:
Input validation
Strong output encoding
Specify the output encoding
Do not use "blacklist" validation
Watch out for canonicalization errors

We also learned how to do an XSS attack. The basic idea is to apply a script such as shown below to create a false login page so that you can harvest the username and password keyed in by the user.



Script Example


Phishing with XSS

The script is then pasted on the above screen. A login page will be created using the Javascript page above. User then logs in with username and password. The username and password will be send across the world to a server that gathers login information.

The next thing we've learnt is about the injection flaws. This flaw allows attackers to relay malicious code through a web application to another system. Various attacks include calls to the operating system via system calls, the use of external programs via shell commands, as well as calls to backend databases via SQL ( or referred to as SQL injection).



The example PHP code shown above can be manipulated by entering



in which it returns all the data from the User Table.
To learn more about injection flaws, please visit http://www.owasp.org/index.php/Injection_Flaws

Malicious File execution is another web application vulnerabilities caused by failing to control application input. In this attack, attacker will exploit the weaknesses by performing
Remote code execution
Remote root kit installation and complete system compromise
On Windows, internal system compromise may be possible through the use of PHP’s SMB file wrappers

This vulnerability can be prevented by:-
• Strongly validate user input using "accept known good" as a strategy
• Add firewall rules to prevent web servers making new connections to external web sites and internal systems. For high value systems, isolate the web server in its own VLAN
or private subnet
• Check user supplied files or filenames cannot obviate other controls, such as tainting data in the session object, avatars and images, PDF reports, temporary files, and so on
• Consider implementing a chroot jail or other sand box mechanisms such as virtualization to isolate applications
from each other
PHP: Disable allow_url_fopen and allow_url_include in
php.ini and consider building PHP locally to not include this functionality. Very few applications need this functionality
and thus these settings should be enabled on a per
application basis
• PHP: Disable register_globals and use E_STRICT to find
uninitialized variables
• PHP: Ensure that all file and streams functions (stream_*)
are carefully vetted