Downloaded 179 times
Uploaded byAnurag Srivastava
Introduction to Web Application Penetration Testing
The document discusses web application penetration testing, focusing on identifying security vulnerabilities such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF). It outlines various critical bugs as per OWASP and provides countermeasures for addressing these vulnerabilities. The author emphasizes the necessity for proper validation and mitigation strategies to enhance web application security.
More Related Content
Similar to Introduction to Web Application Penetration Testing
Introduction to Web Application Penetration Testing
- 1. WEB APPLICATION PENETRATION TESTING Anurag Srivastava Information SecurityResearcher PRE NULL MEET – LUCKNOW
- 2. Introduction To Web- ApplicationPenetration Testing Process to check and penetrate the security of a web application or a website process involves an active analysis of the application for any weaknesses, technical flaws, or vulnerabilities Any security issues that are found will be presented to the system owner, together with an assessment of the impact, a proposal for mitigation or a technical solution.
- 3. Why Web Application PenetrationTesting ? Common Misnomers “Our site is safe” We have Firewalls in place We encrypt our data We have IDS/IPS We have a privacy policy
- 4. Top Ten CriticalBugs According To Owasp ! Injection like Sql ,Os and Ldap Broken Authentication And Session Management XSS – Cross Site Scripting Insecure Direct Object Reference Security Misconfiguration Sensitive Data Exposure Missing Function level Access Control CSRF -Cross Site Request Forgery Using Components with Known Vulnerabilities Unvalidated Redirects and Forwards
- 5. Injection Such AsSql,Os and LDAP Injections Untrusted data is sent to an interpreter as part of a command or query. Attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
- 6.
- 7. Trying the basic- 1' or '1'='1 in the vulnerable input field in order to get the username,password and confirm the sql injection vulnerability Returns true for all
- 8. Blind Sql Injection Itried to execute a sql query in the input field here along with a true return value
- 9. I tried toexecute the “database() “ to extract the db name. query Database Name (DVWA)
- 10. Am I VulnerableTo 'Injection'? Verify that all use of interpreters clearly separates untrusted data from the command or query Code analysis tools can help a security analyst find the use of interpreters and trace the data flow through the application Poor error handling makes injection flaws easier to discover
- 11. XSS – CrossSite Scripting Occurs whenever an application takes untrusted data and sends it to a web browser without proper validation or escaping. Allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
- 13.
- 14. Payload used :-<img src=urloftheimage> Stored XSS
- 15.
- 16. Am I VulnerableTo 'Cross-Site Scripting (XSS)'? Vulnerable if you do not ensure that all user supplied input is properly escaped, or you do not verify it to be safe via input validation, before including that input in the output page. If Ajax is being used to dynamically update the page, are you using safe JavaScript APIs? For unsafe JavaScript APIs, encoding or validation must also be used.
- 17. CSRF – CrossSite Request Forgery Attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application Allows the attacker to force the victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.
- 18.
- 20. The Request doesnothave CSRF token/access token and thus we can take advantage to generate a csrf
- 21. We are usingthe same form which our vulnerable website uses but we are changing the value of the password and thus resetting the password to anything we wish .. <form action="http://127.0.0.1/dvwa/vulnerabilities/csrf/?" method="GET"> New password:<br> <input type="password" AUTOCOMPLETE="off" name="password_new" value="anurag"><br> Confirm new password: <br> <input type="password" AUTOCOMPLETE="off" name="password_conf" value="anurag"><br> <input type="submit" value="Change" name="Change"> </form>
- 22.
- 23. Wow ! Password hasbeen Changed
- 24. Am I VulnerableTo 'Cross-Site Request Forgery (CSRF)'? Check if any links and forms lack an unpredictable CSRF token. Without such a token, attackers can forge malicious requests. An alternate defense is to require the user to prove they intended to submit the request, either through reauthentication, or some other proof they are a real user (e.g., a CAPTCHA).
- 25. Only 10 ? NO, There are not only 10 but hundreds of issues that could affect the overall security of a web application.
- 26. COUNTERMEASURES For Injections- Use a safe API which avoids the use of the interpreter entirely or provides a parameterized interface. For XSS - Properly escape all untrusted data based on the HTML context (body, attribute, JavaScript, CSS, or URL) that the data will be placed into. For CSRF - Include the unique token in a hidden field. Requiring the user to reauthenticate, or prove they are a user (e.g., via a CAPTCHA) can also protect against CSRF.
- 27.