Learning

WebGoat is a deliberately insecure J2EE web application maintained by OWASP 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. 1. Before installing firs download webgoat from this link  . 2. To   extract   the   file   format   7zip, install p7zip by :     apt-get install p7zip 3. Now extract webgoat file :      p7zip -d WebGoat-OWASP_Standard-5.3_RC1.7z 4.  if   the   extract   has been completed , go   into the   folder   extract :     cd  WebGoat-OWASP_Standard-5.3_RC1 5.  change the   file p...

1. WS Information Gathering The first step to perform a Web Service Test is to determine the WS entry points and the communication schema: this is described in the WSDL associated with the WS. 2. Testing WSDL Check the WSDL of the web service to find the entry points and try to invoke an operation that is not used in a standard SOAP Request. Ensure that the WS doesn’t give some confidential information 3. XML Structural Testing This section discusses the types of attack vectors one could send to a web service in an attempt to assess its reaction to malformed or maliciously-crafted messages. For example, elements which contain large numbers of attributes can cause problems with parsers. This category of attack also includes XML documents which are not well-formed XML (e.g., with overlapping elements, or with open tags that have no matching close tags). DOM-based parsing can be vulnerable to DoS due to the fact that the complete message is loaded into memory (as opposed to SAX pa...

1. AJAX Vulnerabilities Asynchronous Javascript and XML (AJAX) is one of the latest techniques used by web application developers to provide a user experience similar to that of a local application. Since AJAX is still a new technology, there are many security issues that have not yet been fully researched. Some of the security issues in AJAX include: • Increased attack surface with many more inputs to secure • Exposed internal functions of the application • Client access to third-party resources with no built-in security and encoding mechanisms • Failure to protect authentication information and sessions • Blurred line between client-side and server-side code, resulting in security mistakes 2. How to test AJAx Because most attacks against AJAX applications are analogs of attacks against traditional web applications, testers should refer to other sections of the testing guide to look for specific parameter manipulations to use in order to discover vulnerabilities. The challenge...

1. Testing for SQL Wildcard_Attacks 2. D Locking Customer Accounts In this test we check whether an attacker can lock valid user accounts by repeatedly attempting to log in with a wrong password. when we try to login by exist account and wrong password or  by not exist account and wrong password we get the following error message : when we try to register by the axist account we get the following error message : 3. Buffer Overflows 4. User Specified Object Allocation In this test we check whether it is possible to exhaust server resources by making it allocate a very high number of objects. Our targets can not be attacked using this method:   5. User Input as a Loop Counter 6. Writing User Provided Data to Disk With this test, we check that it is not possible to cause a DoS condition by filling the target disks with log data 7. Failure to Release Resources With this test, we check that the application properly releases resources (files and/...

Testing for Cross site scripting In Cross Site Scripting (XSS) testing, we test if it is possible to manipulate the input parameters of the application so that it generates malicious output. We find an XSS vulnerability when the application does not validate our input and creates an output that is under our control. This vulnerability leads to various attacks, for example, stealing confidential information (such as session cookies) or taking control of the victim's browser. An XSS attack breaks the following pattern: Input -> Output == cross-site scripting In this guide, the following types of XSS testing are discussed in details: 1. Testing for Reflected Cross Site Scripting A black-box test will include at least three phases:    1. Detect input vectors. The tester must determine the web application’s variables and how to input them in the web application. See the example below.    2. Analyze each input vector to detect potential vulnerabilities. To detect...

Testing for business logic flaws in a multi-functional dynamic web application requires thinking in unconventional ways. If an application's authentication mechanism is developed with the intention of performing steps 1,2,3 in order to authenticate, what happens if you go from step 1 straight to step 3? In this simplistic example, does the application provide access by failing open, deny access, or just error out with a 500 message? There are many examples that can be made, but the one constant lesson is "think outside of conventional wisdom". This type of vulnerability cannot be detected by a vulnerability scanner and relies upon the skills and creativity of the penetration tester. In addition, this type of vulnerability is usually one of the hardest to detect, but, at the same time, usually one of the most detrimental to the application, if exploited.

1. Testing for Path Traversal First, we test if it is possible to find a way to execute a path traversal attack and access reserved information About input vector: 2. Testing for bypassing authorization schema This kind of test focuses on verifying how the authorization schema has been implemented for each role/privilege to get access to reserved functions/resources. 3. Testing for Privilege Escalation During this phase, the tester should verify that it is not possible for a user to modify his or her privileges/roles inside the application in ways that could allow privilege escalation attacks.

1. Testing for Session Management Schema This describes how to analyse a Session Management Schema, with the goal to understand how the Session Management mechanism has been developed and if it is possible to break it to bypass the user session. It explains how to test the security of session tokens issued to the client's browser: how to reverse engineer a cookie, and how to manipulate cookies to hijack a session. use addons Add & Edit cookies : result : 2. Testing for Cookies attributes Cookies are often a key attack vector for malicious users (typically, targeting other users) and, as such, the application should always take due diligence to protect cookies. In this section, we will look at how an application can take the necessary precautions when assigning cookies and how to test that these attributes have been correctly configured. This Cookies atribut we found : akakom_tpl=akakom; __utma=242819602.2057941145.1307427908.1307427908.1307430421.2; __utmz=242819602...