WebGoat
WebGoat is a deliberately insecure J2EE web application designed to teach web application security lessons. In each lesson, users must demonstrate their understanding of a security issue by exploiting a real vulnerability in the WebGoat application. For example, in one of the lessons the user must use SQL injection to steal fake credit card numbers. The application is a realistic teaching environment, providing users with hints and code to further explain the lesson.
The primary goal of the WebGoat project is simple which is created a de-facto interactive teaching environment for web application security. In the future, the project team hopes to extend WebGoat into becoming a security benchmarking platform and a Java-based Web site Honey pot.
To learn more about WebGoat, you can visit this link anytime: http://code.google.com/p/webgoat/source/browse/trunk/webgoat/main/project/WebContent/lesson_plans/HowToWork.html
Injection Flaws
Injection flaw like SQL injection will cause web application to run an SQL code that was not intended by the application. Usually user supplied data from an application is sent to an interpreter as a query command. With the knowledge of SQL query syntax the attacker exploit this feature by crafting a special crafted data to execute exploit command to the interpreter. By doing this attacker can create, read, update or delete any data available in the database through the web application.
The simplest way to protect against injection is to avoid accessing external interpreters wherever possible. For many shell commands and some system calls, there are language specific libraries that perform the same functions. Using such libraries does not involve the operating system shell interpreter, and therefore avoids a large number of problems with shell commands.
For those calls that you must still employ, such as calls to backend databases, you must carefully validate the data provided to ensure that it does not contain any malicious content. You can also structure many requests in a manner that ensures that all supplied parameters are treated as data, rather than potentially executable content.
The use of stored procedures or prepared statements will provide significant protection, ensuring that supplied input is treated as data. These measures will reduce, but not completely eliminate the risk involved in these external calls. You still must always validate such input to make sure it meets the expectations of the application in question. For more details on how to specifically defend against SQL Injection, please refer to OWASP's SQL Injection Prevention Cheat Sheet.
Malicious File Execution
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 and 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
In other word this kind of attack will manipulate your web application to become the attacker remote terminal to execute command line instructions such as directory list, dir or displaying
network configuration, ipconfig. It will become more dangerous if the attacker manipulate this vulnerability by executing command that can create a backdoor to your server.
