The document presents a comprehensive overview of how to test for the OWASP Top Ten security vulnerabilities in web applications, detailing specific threats such as injection attacks, broken authentication, and cross-site scripting. It outlines steps to identify vulnerabilities, create test data, and analyze responses to safeguard against unauthorized access and data exposure. Additionally, it emphasizes the importance of security best practices and offers resources for further training and assessment in application security.

1. 1
How to Test for the
OWASP Top Ten:
Presented by: Jason Taylor, CTO
#TestingforOWASP

2. 2
About Security Innovation
• Authority in Software Security
• 15+ years research on software vulnerabilities
• Platform Centers of Excellence for specialization
• Authors of 18 books, 11 with Microsoft
• Gartner Magic Quadrant Leader 3 years in a row
• Helping organizations minimize risk,
regardless of problem complexity
ASSESSMENT - Show me the Gaps!
STANDARDS - Set goals and make it easy
EDUCATION - Enable me to make the right decisions
About Security Innovation

3. 3
Current OWASP Top Ten List
A1 – Injection
A2 – Broken Authentication and Session Management
A3 – Cross‐Site Scripting (XSS)
A4 – Insecure Direct Object References
A5 – Security Misconfiguration
A6 – Sensitive Data Exposure
A7 – Missing Function Level Access Control
A8 – Cross‐Site Request Forgery (CSRF)
A9 – Using Components with Known Vulnerabilities
A10 – Unvalidated Redirects and Forwards

4. 4
A1: Injection, the Web's Greatest Risk
• Occurs because a developer improperly mixes code and data which gets executed
as a command
• Includes SQL, OS, LDAP, XML and Xpath Injection
• Successful injection allows an attacker to:
• Steal content from files or data from tables not accessible via the interface
• Insert or update malicious content in the database
• Gain complete access to the database server and/or networked servers
• Important to understand how application will interpret the input, for example:

5. 5
Common Testing Steps
1. Identify Entry Points. Where can you feed malicious data?
2. Create Test Data. What attack strings do you want try?
3. Analyze the Response. Make sure you know what a
successful attack response looks like.
4. Dig In. Determine which bad responses are potentially
exploitable

6. 6
SQL Injection
1. Identify Entry Points
1. Does the feature interact with a backend database?
2. Does it seem like input is used to form the query?
2. Create Test Data
1. ‘ is a string terminator
2. ; is a statement terminator
3. Fuzz data like: xyz') "]
3. Analyze the Response
1. Often will get a server error, sometimes a full stack trace
2. Other times you may see unusual application behavior
4. Dig In
1. xyz' OR 1=1; --
2. xyz' OR 1>2; --

7. 7
Demo – Login SQLi

8. 8
XML Injection
1. Identify Entry Points
1. Look for web services that use XML or SOAP
2. Look for storage of structured XML data
3. Look for XML that is generated by user input
2. Create Test Data
1. Can you add additional tags to store information in the store?
2. Are there CDATA tags that are being used for HTML or Script processing?
3. Create xml fuzz strings using control characters (‘, “, <, >, > ' "<, xyz<!--)
3. Analyze the Response
1. Do you see an XML related error?
2. Do you see your characters added to the XML
4. Dig In
1. Learn from the error message to create a real attack
2. Where is the error coming from? What tags are you impacting?
3. <![CDATA[<script>alert('XSS')</script>]]>

9. 9
XML Injection
• Invalid XML:
<user name='''/>
<id ='1232'/>
<realname='tester'>
<password='ind3$truct'/>
<user>

10. 10
XML Injection
• Attack String:
attacker'><id
='1234'/><realname='hacker'><password='qwerty'/></user><us
er name ='real_user

11. 11
XML Injection
• Result
<user name='attacker'/>
<id ='1234'/>
<realname='hacker'>
<password='ind3$truct'/>
</user>
<user name='real_user'/>
<id ='1232'/>
<realname='tester'>
<password='realuserpassword'/>
</user>

12. 12
Demo – XML Injection

13. 13
A2 – Broken Authentication & Session
Management
• Web sites use session identifiers (IDs) to identify users after logging in
• Session IDs are stored in cookies and hidden fields in the URL
• When improperly handled, it can be stolen by attackers and reused to
hijack an online identity or account
• Major threats can include
• Stealing another user’s session and masquerading as that user.
• Performing sensitive operations as the user whose session was stolen.
• If an admin portal exists, eventually gaining complete control of the en re application

14. 14
Checking for Unprotected Credentials and
Session IDs
• Check if credentials are protected when stored using hashing or encryption. This is possible
only if access to the source code is available
• Check if account management functions (e.g. account creation, password changes, weak
session IDs) are implemented in a secure manner
• Check if session IDs:
• Are transmitted as query string parameters in the URL
• Are changed after a user successfully logs in to the application
• Time out after a period of inactivity
• Ensure that the application allows a user to log out and terminates session on the server
• Ensure that all passwords, session IDs, and other sensitive information are sent over TLS
• Check if Web application allows a user to authenticate using a previous or existing session ID
• Check if you are able to force a known session ID on a user

15. 15
A3 – Cross-Site Scripting (XSS)
• Injection attack where application accepts input without
proper validation then uses that input to generate output
• Occurs any time raw data from attacker is sent to an
innocent user’s browser
• Raw data…
• Stored in database
• Reflected from web input
• Sent directly into rich JavaScript client
• Virtually every web application has this problem
• Typical Impact
• Steal user’s session, steal sensitive data, rewrite web page, redirect
user to phishing or malware site
• Most Severe: Install XSS proxy which allows attacker to observe and direct all user’s behavior
on vulnerable site and force user to other sites

16. 16
1. Identify Entry Points
1. Where is user input impacting HTML or script generation?
2. Where is user input copied directly into HTML?
3. Where is user supplied data from the database used to create generate HTML?
2. Create Test Data
1. "><script>alert(‘Test')</script>
2. "><img src="javascript:alert(’Test');"</img>
3. "><body onload=alert(’Test')>
3. Analyze the Response
1. Do you get a server error?
2. Do you see an script alert popup?
4. Dig In
1. Place attack data in one part of the website, retrieve it in another
2. For instance a comments section or feedback form

17. 17
Demo – XSS

18. 18
A4 – Insecure Direct Object References
• Occurs when a developer exposes a reference to an internal implementation
object:
• Files
• Directories
• Database keys
• Without an access control check or other protection, attackers can
manipulate references to internal implementation objects and access
unauthorized data
• Major threats:
• Anonymous users can gain access to private content.
• Unauthorized users can perform operations on assets owned by other users

19. 19
Perform these tests using user accounts that have
different privilege levels
1. Identify user input points – such as query string parameters, POST
body parameters, or cookies – that the application uses to decide
which object to display to the user.
2. Identify if the application returns data not associated with the user, by
modifying the parameters.

20. 20
Demo – URL Params

21. 21
A5 – Security Misconfiguration
• Insecure configuration within operating systems, web services, and
databases increases your attack surface
• Can impact your development environment as well as users of your
system
• Development and Operations teams should work together to ensure
seamless transition from development to production

22. 22
How to Check for Security Misconfiguration
• Is your server hardened?
• Can any code libraries or applications be uninstalled?
• Is the web server, application server and db server configured for maximum security?
• Are enabled accounts kept to a minimum?
• Is the file system configured for maximum security?
• Are you logging all security-sensitive events?
• Are all patches installed?
• Is your application configured securely?
• Is the default configuration secure?
• Are the passwords changed from the defaults?
• Are all test interfaces and users accounts removed?
• Is debug information turned off?
• Use an automated scanner to help

23. 23
A6 – Sensitive Data Exposure
• Two modes: insecure storage and insecure transmission
• Strong encryption is vital in protecting secrets, but often comes late in the
development process as an afterthought or low‐priority enhancement
• Common mistakes:
• Failure to encrypt
• Weak encryption
• Failure to protect passwords (e.g. weak hashing)
• Failure to protect encryption keys (e.g. storing the keys alongside the
encrypted data)

24. 24
How to Check for Sensitive Data Exposure
This is a pretty wide ranging topic
• Identify the sensitive data your application needs to protect
• Where is it being stored?
• How is it being stored? Encrypted? Hashed?
• See what you can do to get access and steal in plain text

25. 25
Demo – Decrypt Hash

26. 26
A7 – Missing Function Level Access Control
• Most applications have authorization requirements to restrict access to sensitive
functions
• Insufficient controls allow attackers to access features and functionality that
should be off limits
• Impact varies based on your business logic but could include:
• Administrative features
• Access or modification to sensitive data
• Access to application details that can aid another attack
• The problem is usually caused by
• Misconfiguration of access controls
• Failure to authorize the user on each function
• Reliance on client-side information or processing

27. 27
Checking for Missing Function Level Access
Control Vulnerabilities
• Identify sensitive actions performed by the application
• Check if an unauthorized user/user of lower privileged role can perform them
• Check if UI shows links to unauthorized functionality for any user
• Confirm that checks are performed on both the client and server side
• Perform tests with user accounts that have different privilege levels
Example

28. 28
A8 – Cross Site Request Forgery (CSRF)
• An attack where victim’s browser is tricked into
issuing a command to a vulnerable web application
• Example
• Although an attacker cannot access this URL without
being an admin, they can use a CSRF attack to get
an admin to access it on their behalf
• Vulnerability is caused by browsers automatically
including user authentication data with each request
• Typical Impact
• Initiate transactions (transfer funds, logout user, close
account)
• Access sensitive data
• Change account details

29. 29
How to Check for CSRF
• Identify HTTP Requests that result in a sensitive operation
• Create a URL that can be used to execute the action and send it to your test account in an
email
• Click on the URL from the context of a privileged user
• Does the operation occur or is it blocked?
• If blocked, ensure its based on a truly random token

30. 30
A9- Using Components with Known
Vulnerabilities
• Even when following security best practices, websites can still be vulnerable due to
3rd party components
• External code can be a large part of an application’s code base
• Exploiting known flaws in components is particularly attractive to attackers because
• The vulnerability can impact many systems
• Attackers know it can be hard to stay up to date
• Exploit code is often widely available immediately after
flaw is made public
• New tools make it easy to automate massive attacks and
compile lists of vulnerable sites through search engines

31. 31
Checking for and Preventing Vulnerable
Components
• Identify all software components used by the application and determine
any security advisories for the version of the software
• Common Vulnerabilities and Exposures (CVE) is useful for this
• Confirm that all your software is up to date
• This includes the OS, Web/App Server, DBMS, applications, and all code libraries.
• Subscribe to notifications for new and updated versions of all components
• Use both manual and automated reviews to identify security flaws in any
components you implement, whenever possible
• Install all vendor‐ released patches that fix the vulnerability.
• If vendor patch isn’t available, consider installing operational compensatory controls

32. 32
A10 – Unvalidated Redirects and Forwards
• Often used to direct a user to another site or to a page on the
same site
• Some websites allow the redirection to be manipulated e.g. a
URL parameter
• Can be used for phishing – redirect to malicious site
• May also be used to bypass access control
• Typical Impact
• Redirect victim to phishing or malware site
• Attacker’s request is forwarded past security checks, allowing unauthorized function or data
access

33. 33
Checking for Unvalidated Redirects and
Forwards
• Review your code for all use of redirects
• Check to see if the redirect is static or calculated based on input
• An automated scan can identify redirect response codes (e.g. 302)
• Confirm whether the application uses any user‐supplied data, such as query string
parameters or cookies, to determine how to redirect the user
• Determine if it is possible to redirect a user out of the application to an attacker‐controlled
page by manipulating the data used to create the redirect.
Example

34. 34
Conclusion
• The OWASP Top 10 was designed as a
way to publicize the top threats to web applications
• You can use it for:
• Education
• Organization of best practices and SDLC initiatives
• As a call to action for your development organization
• The Top 10 maps well to a variety of compliance standards
• Protection against the Top 10 will help you fulfill your application
security compliance requirements

35. 35
How Security Innovation Can Help
Instructor-Led and Computer Based Training
• 100+ courses for all major roles, technologies and platforms
• OWASP Top Ten covered in dozens of courses
Application Security Assessments
• Zero false positives
• Contextual remediation guidance
CMD+CTRL Capture the Flag Web sites
• Banking, HR, Retail and Mobile applications
• 300+ vulnerabilities; coverage for all OWASP Top Ten

36. 36
What’s Next?
• On-Demand Webcast: OWASP Top Ten: Threats & Mitigations
https://www.youtube.com/watch?v=XHc4JPO6Orw
• OWASP Software Security Assessment
https://web.securityinnovation.com/owasp-top-10-penetration-test
• 7-Day Free Trial for our Top OWASP training courses
https://appsec.securityinnovation.com?KeyName=vj9y6TKYSQAIz_kcvetT
• Questions? Email: getsecure@securityinnovation.com
Thank You!