OWASP_Top_10_Introduction_and_Remedies_2017

1. Copyright 2007 © The OWASP Foundation
Permission is granted to copy, distribute and/or modify this document
under the terms of the OWASP License.
The OWASP Foundation
OWASP
http://www.owasp.org
OWASP Top 10
Introduction & Remedies
Module (to be combined)
Education Project

2. OWASP 2
Introduction

3. OWASP 3
OWASP Top 10
The Ten Most Critical
Web Application Security
Vulnerabilities
2007 Release
A great start, but not a
standard

4. OWASP 4
OWASP Top 10 2007
1. Cross Site Scripting (XSS)
2. Injection Flaws
3. Insecure Remote File Include
4. Insecure Direct Object Reference
5. Cross Site Request Forgery (CSRF)
6. Information Leakage and Improper Error Handling
7. Broken Authentication and Session Management
8. Insecure Cryptographic Storage
9. Insecure Communications
10. Failure to Restrict URL Access
http://www.owasp.org/index.php/Top_10

5. OWASP 5
Top 10 Methodology
Take the MITRE Vulnerability Trends for 2006, and distill
the Top 10 web application security issues

6. OWASP 6
OWASP Top 10 2007 OWASP Top 10 2004 MITRE 2006
Raw Ranking
1. Cross Site Scripting (XSS) 4. Cross Site Scripting (XSS) 1
2. Injection Flaws 6. Injection Flaws 2
3. Insecure Remote File Include (NEW) 3
4. Insecure Direct Object Reference 2. Broken Access Control (split in 2007 T10) 5
5. Cross Site Request Forgery (CSRF) (NEW) 36
6. Info Leakage and Improper Error Handling 7. Improper Error Handling 6
7. Broken Auth. and Session Management 3. Broken Authentication and Session Management 14
8. Insecure Cryptographic Storage 8. Insecure Storage 8
9. Insecure Communications (NEW) Discussed under 10 8
10. Failure to Restrict URL Access 2. Broken Access Control (split in 2007 T10) 14
1. Unvalidated Input 7
5. Buffer Overflows 4, 8, and 10
9. Denial of Service 17
10. Insecure Configuration Management 29
Top 10 Mapping

7. OWASP 7
Cross Site Scripting (XSS)

8. OWASP 8
1. Cross-Site Scripting (XSS)
Description
Most prevalent web application security issue
Allows attackers to execute script in the victim’s
browser
Affected Environments
All web application frameworks are vulnerable to
cross site scripting

9. OWASP 9
1. Cross-Site Scripting (XSS)
Vulnerabilities
Three types:
 Reflected
 Stored
 DOM injection
Attacks are normally implemented in JavaScript or
direct manipulation of request objects

10. OWASP 10
1. Cross-Site Scripting (XSS)
Verifying Security
All input parameters are validated and/or encoded
Code Reviews are useful to detect
Centralized validation and encoding mechanism
Protection
Combination of whitelist validation of all incoming
data and appropriate encoding of all output data

11. OWASP 11
1. Cross-Site Scripting (XSS)
 References
 OWASP – Cross site scripting,
http://www.owasp.org/index.php/Cross_Site_Scripting
 OWASP – Testing for XSS,
http://www.owasp.org/index.php/Testing_for_Cross_site_scripting
 OWASP Stinger Project (A Java EE validation filter) –
http://www.owasp.org/index.php/Category:OWASP_Stinger_Project
 OWASP PHP Filter Project -
http://www.owasp.org/index.php/OWASP_PHP_Filters
 OWASP Encoding Project -
http://www.owasp.org/index.php/Category:OWASP_Encoding_Project
 RSnake, XSS Cheat Sheet, http://ha.ckers.org/xss.html
 Klein, A., DOM Based Cross Site Scripting,
http://www.webappsec.org/projects/articles/071105.shtml
 .NET Anti-XSS Library -
http://www.microsoft.com/downloads/details.aspx?FamilyID=efb9c819-53ff-
4f82-bfaf-e11625130c25&DisplayLang=en
 Wikipedia Definition –
http://en.wikipedia.org/wiki/Cross-site_scripting

12. OWASP 12
Injection Flaws

13. OWASP 13
2. Injection Flaws
Description
Injection occurs when user-supplied data is sent to
an interpreter as part of a command or query
SQL injection is the most common
Affected Environments
All web application frameworks that use interpreters
are vulnerable to injection attacks.

14. OWASP 14
2. Injection Flaws
Vulnerabilities
If user input is passed into an interpreter without
validation or encoding, the application is vulnerable.
Check to see if user input is supplied directly to
dynamic queries

15. OWASP 15
2. Injection Flaws
Verifying Security
Verify that the user can not modify commands or queries sent to
any interpreter used by the application
Code Reviews are useful to detect
Protection
Avoid interpreters where possible
Enforce least privilege
Stored procedures are susceptible too
User input validation

16. OWASP 16
2. Injection Flaws
 References
 OWASP, http://www.owasp.org/index.php/SQL_Injection
 OWASP, http://www.owasp.org/index.php/Guide_to_SQL_Injection
 OWASP, http://www.owasp.org/index.php/Reviewing_Code_for_SQL_Injection
 OWASP, http://www.owasp.org/index.php/Testing_for_SQL_Injection
 SQL Injection, http://www.spidynamics.com/papers/SQLInjectionWhitePaper.pdf
 Advanced SQL Injection, http://www.ngssoftware.com/papers/advanced_sql_injection.pdf
 More Advanced SQL Injection,
http://www.nextgenss.com/papers/more_advanced_sql_injection.pdf
 Hibernate, an advanced object relational manager (ORM) for J2EE and .NET,
http://www.hibernate.org/
 J2EE Prepared Statements,
http://java.sun.com/docs/books/tutorial/jdbc/basics/prepared.html
 How to: Protect from SQL injection in ASP.Net,
http://msdn2.microsoft.com/en-us/library/ms998271.aspx
 PHP PDO functions, http://php.net/pdo

17. OWASP 17
Insecure Remote File Include

18. OWASP 18
3. Malicious File Injection
Description
Allows attackers to perform remote code execution
etc by compromising input files or streams; commonly
caused by improperly trusting input files
Affected Environments
All web application frameworks that allow uploaded
files to be executed are vulnerable
Environments are susceptible if they allow file upload
into web directories.

19. OWASP 19
3. Malicious File Injection
Vulnerabilities
Hostile data being uploaded to session files or log
data
PHP is most common, other technologies are
accessible too
 Java and .Net
 Hostile DTD in XML Documents

20. OWASP 20
3. Malicious File Injection
Verifying Security
Code Reviews are useful to detect
Automated tools are useful
Protection
Do not allow a user defined file name to supply
server-based resources
Properly configured and implemented security
protocols
User input validation

21. OWASP 21
3. Malicious File Injection
 References
 OWASP Guide,
http://www.owasp.org/index.php/File_System#Includes_and_Remote_files
 OWASP Testing Guide,
http://www.owasp.org/index.php/Testing_for_Directory_Traversal
 OWASP PHP Top 5,
http://www.owasp.org/index.php/PHP_Top_5#P1:_Remote_Code_Execution
 Stefan Esser,
http://blog.php-security.org/archives/45-PHP-5.2.0-and-allow_url_include.html
 [SIF01] Sift Networks, Web Services: Teaching an old dog new tricks,
http://www.ruxcon.org.au/files/2006/web_services_security.ppt
 http://www.owasp.org/index.php/OWASP_Java_Table_of_Contents#Defining_a_J
ava_Security_Policy
 Microsoft - Programming for Partial Trust, http://msdn2.microsoft.com/en-
us/library/ms364059(VS.80).aspx

22. OWASP 22
Insecure Direct Object Reference

23. OWASP 23
4. Insecure Direct Object Reference
Description
Occurs when a developer exposes an invalidated
reference to an internal implementation object, such
as a file, directory, database record, or key, as a URL
or form parameter
Affected Environments
All web application frameworks are vulnerable to
attacks on insecure direct object references

24. OWASP 24
4. Insecure Direct Object Reference
Vulnerabilities
Exposed internal object references
Attackers use parameter tampering to change
references and violate the intended but unenforced
access control policy
References to database keys are frequently exposed

25. OWASP 25
4. Insecure Direct Object Reference
Verifying Security
Remove any direct object references that can be
manipulated by an attacker
Difficult for both automated and manual approaches
Protection
Best protection is to avoid exposing direct object
references to users
Verify authorization to all referenced objects

26. OWASP 26
4. Insecure Direct Object Reference
References
 OWASP, http://www.owasp.org/index.php/Testing_for_business_logic
 OWASP,
http://www.owasp.org/index.php/Testing_for_Directory_Traversal
 OWASP,
http://www.owasp.org/index.php/Category:Access_Control_Vulnerability

27. OWASP 27
Cross Site Request Forgery (CSRF)

28. OWASP 28
5. Cross Site Request Forgery (CSRF)
Description
An attack that tricks the victim into loading a page
that contains a malicious request.
Also known as Session Riding, One-Click Attacks,
Cross Site Reference Forgery, Hostile Linking, and
Automation Attack
Affected Environments
All web application frameworks are vulnerable to
CSRF.

29. OWASP 29
5. Cross Site Request Forgery (CSRF)
Vulnerabilities
In a forum, the attack may direct the user to invoke a
logout function
 Can be combined with XSS

30. OWASP 30
5. Cross Site Request Forgery (CSRF)
Verifying Security
Use an authorization token that is not automatically submitted
by browser
Protection
Eliminate any XSS vulnerabilities in your application
Add a per-request nonce to URL and all forms in addition to the
standard session; if it is not built into your web app framework.
Require additional login screens for sensitive data
Do not use GET requests for sensitive data

31. OWASP 31
5. Cross Site Request Forgery (CSRF)
 References
 OWASP CSRF, http://www.owasp.org/index.php/Cross-
Site_Request_Forgery
 OWASP, https://www.owasp.org/index.php/Testing_for_CSRF
 OWASP CSRF Guard, http://www.owasp.org/index.php/CSRF_Guard
 OWASP PHP CSRF Guard,
http://www.owasp.org/index.php/PHP_CSRF_Guard
 RSnake, "What is CSRF?", http://ha.ckers.org/blog/20061030/what-is-
csrf/
 Microsoft, ViewStateUserKey details,
http://msdn2.microsoft.com/en-
us/library/ms972969.aspx#securitybarriers_topic2

32. OWASP 32
Information Leakage and Improper Error Handling

33. OWASP 33
6. Information Leakage and Improper Error Handling
Description
Applications can unintentionally leak information
about their configuration, internal workings, or violate
privacy through a variety of application problems
Affected Environments
All web application frameworks are vulnerable to
information leakage and improper error handling.

34. OWASP 34
6. Information Leakage and Improper Error Handling
Vulnerabilities
Error message with too much detail
 Stack Traces
 SQL Statements
Improper logging of detailed messages

35. OWASP 35
6. Information Leakage and Improper Error Handling
Verifying Security
The goal is for the application to not leak detailed error
messages
Automated and Manual approaches are useful, but automated
can not properly determine the meaning of the message and
manual is time consuming
Protection
Use testing to generate error messages and perform ongoing
evaluations in development
Disable or limit detailed error handling

36. OWASP 36
6. Information Leakage and Improper Error Handling
References
 OWASP http://www.owasp.org/index.php/Error_Handling
 OWASP
http://www.owasp.org/index.php/Category:Sensitive_Data_Protection_
Vulnerability

37. OWASP 37
Broken Authentication and Session Management

38. OWASP 38
7. Broken Authentication and Session Management
Description
Flaws in authentication and session management
most frequently involve the failure to protect
credentials and session tokens through their lifecycle.
Affected Environments
All web application frameworks are vulnerable to
authentication and session management flaws

39. OWASP 39
7. Broken Authentication and Session Management
Vulnerabilities
Flaws in main authentication mechanism
Password management
Session Timeout

40. OWASP 40
7. Broken Authentication and Session Management
 Verifying Security
 Application should properly authenticate users and protect their
credentials
 Automated tool have difficulty
 Combination of Code Reviews and Testing are effective
 Protection
 Maintain secure communication and credential storage
 Use single authentication mechanism where applicable
 Create a new session upon authentication
 Ensure the logout link destroys all pertinent data
 Do not expose any credentials in URL or logs

41. OWASP 41
7. Broken Authentication and Session Management
References
 OWASP, http://www.owasp.org/index.php/Guide_to_Authentication
 OWASP,
http://www.owasp.org/index.php/Reviewing_Code_for_Authentication
 OWASP, http://www.owasp.org/index.php/Testing_for_authentication

42. OWASP 42
Insecure Cryptographic Storage

43. OWASP 43
8. Insecure Cryptographic Storage
Description
Simply failing to encrypt sensitive data is very
widespread.
Applications that do encrypt frequently contain poorly
designed cryptography, either using inappropriate
ciphers or making serious mistakes using strong
ciphers.
Affected Environments
All web application frameworks are vulnerable to
insecure cryptographic storage.

44. OWASP 44
8. Insecure Cryptographic Storage
Vulnerabilities
Not encrypting sensitive data
Using home grown algorithms
Insecure use of strong algorithms
Continued use of proven weak algorithms (MD5, SHA-
1, RC3, RC4, etc…)
Hard coding keys, and storing keys in unprotected
stores

45. OWASP 45
8. Insecure Cryptographic Storage
Verifying Security
Verify that the application properly encrypts sensitive
information in storage
Automated vulnerability tools are not effective
Code Review is the best way to verify that an application
encrypts sensitive data
Protection
Use only approved public algorithms
Check to make sure all sensitive data is being encrypted

46. OWASP 46
8. Insecure Cryptographic Storage
 References
 OWASP, http://www.owasp.org/index.php/Cryptography
 OWASP, http://www.owasp.org/index.php/Guide_to_Cryptography
 OWASP, http://www.owasp.org/index.php/Insecure_Storage
 OWASP,
http://www.owasp.org/index.php/How_to_protect_sensitive_data_in_U
RL’s
 PCI Data Security Standard v1.1,
https://www.pcisecuritystandards.org/pdfs/pci_dss_v1-1.pdf
 Bruce Schneier, http://www.schneier.com/
 CryptoAPI Next Generation, http://msdn2.microsoft.com/en-
us/library/aa376210.aspx

47. OWASP 47
Insecure Communications

48. OWASP 48
9. Insecure Communications
Description
Applications frequently fail to encrypt network traffic
when it is necessary to protect sensitive
communications
SSL must be used for all authenticated connections
Affected Environments
All web application frameworks are vulnerable to
insecure communications.

49. OWASP 49
9. Insecure Communications
Vulnerabilities
Network sniffing
All authenticated traffic needs to go over SSL because
HTTP includes authentication credentials or a session
token with every single request; not just the actual
login request
Always use SSL with sensitive data

50. OWASP 50
9. Insecure Communications
Verifying Security
Verify that the application properly encrypts all
authenticated and sensitive communications
Vulnerability scanning tools can verify that SSL is
used on the front end, and can find many SSL related
flaws
Code review is quite efficient for verifying the proper
use of SSL for all backend connections
Protection
Always use SSL with sensitive data

51. OWASP 51
9. Insecure Communications
 References
 OWASP Testing Guide, Testing for SSL / TLS,
https://www.owasp.org/index.php/Testing_for_SSL-TLS
 OWASP Guide,
http://www.owasp.org/index.php/Guide_to_Cryptography
 Foundstone - SSL Digger,
http://www.foundstone.com/index.htm?subnav=services/navigation.ht
m&subcontent=/services/overview_s3i_des.htm
 NIST, SP 800-52 Guidelines for the selection and use of transport layer
security (TLS) Implementations,
http://csrc.nist.gov/publications/nistpubs/800-52/SP800-52.pdf
 NIST SP 800-95 Guide to secure web services,
http://csrc.nist.gov/publications/drafts.html#sp800-95

52. OWASP 52
Failure to Restrict URL Access

53. OWASP 53
10. Failure to Restrict URL Access
Description
Relying on security by obscurity to restrict URL access
Not using access control checks for URLs
Affected Environments
All web application frameworks are vulnerable to
failure to restrict URL access

54. OWASP 54
10. Failure to Restrict URL Access
Vulnerabilities
Forced browsing
“Hidden” URLs and files
Outdated security mechanism
Evaluating privileges only on the client

55. OWASP 55
10. Failure to Restrict URL Access
Verifying Security
Verify that access control is enforced consistently for all URLs in
the application
Automated tools have difficulty verifying URL access control
Combination of Code Reviews and Testing are effective
Protection
Properly architecting and implementing roles for URL access
Ensure all URLs are part of this process
Do not use “hidden” URLs

56. OWASP 56
10. Failure to Restrict URL Access
References
 OWASP,
http://www.owasp.org/index.php/Testing_for_Directory_Traversal
 OWASP, http://www.owasp.org/index.php/Forced_browsing
 OWASP, http://www.owasp.org/index.php/Guide_to_Authorization