Copyright © The OWASP FoundationPermission 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

Sergey KocherganLuxoft

22 May 2016

OWASP 2

A1 Injection A2 Broken Authentication and Session Man

agement

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

OWASP

A1 Injection

Injection flaws occur when an application sends untrusted data to an interpreter. Injection flaws are very prevalent, particularly in legacy code. They are often found in SQL, LDAP, Xpath, or NoSQL queries; OS commands; XML parsers, SMTP Headers, program arguments, etc. Injection flaws are easy to discover when examining code, but frequently hard to discover via testing. Scanners and fuzzers can help attackers find injection flaws.

3

OWASP

Prevent Injection

Render: Set a correct content type Set safe character set (UTF-8) Set correct locale On Submit: Enforce input field type and lengths. Validate fields and provide feedback. Ensure option selects and radio contain

only sent values.

4

OWASP

A2 Broken Authentication and Session Management Developers frequently build custom

authentication and session management schemes, but building these correctly is hard. As a result, these custom schemes frequently have flaws in areas such as logout, password management, timeouts, remember me, secret question, account update, etc. Finding such flaws can sometimes be difficult, as each implementation is unique.

5

OWASP

Prevent Broken Authentication and Session Management Only use inbuilt session management. Store secondary SSO / framework / custom

session identifiers in native session object – do not send as additional headers or cookies.

Validate user is authenticated. Validate role is sufficient to perform this action. Validate CSRF token. Set "secure" and "HttpOnly" flags for session

cookies. Send CSRF token with forms.

6

OWASP

A3 Cross-Site Scripting (XSS)

XSS is the most prevalent web application security flaw. XSS flaws occur when an application includes user supplied data in a page sent to the browser without properly validating or escaping that content. There are two different types of XSS flaws: 1) Stored and 2) Reflected, and each of these can occur on the a) Server or b) on the Client.

Detection of most Server XSS flaws is fairly easy via testing or code analysis. Client XSS is very difficult to identify.

7

OWASP

Prevent XSS

Render: Set correct content type and character setOutput encode all user data as per output

context Set input constraints On Submit: Enforce input field type and lengths. Validate fields and provide feedback. Ensure option selects and radio contain only

sent values. 8

OWASP

A4 Insecure Direct Object References

Applications frequently use the actual name or key of an object when generating web pages. Applications don’t always verify the user is authorized for the target object. This results in an insecure direct object reference flaw. Testers can easily manipulate parameter values to detect such flaws. Code analysis quickly shows whether authorization is properly verified.

9

OWASP

Prevent Insecure Direct Object References If data is from internal trusted sources, no

data is sent. Send indirect random access reference

map value. Obtain direct value from random access

reference access map. Validate role is sufficient to create, read,

update, or delete data.

10

OWASP

A5 Security Misconfiguration

Security misconfiguration can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Developers and system administrators need to work together to ensure that the entire stack is configured properly. Automated scanners are useful for detecting missing patches, misconfigurations, use of default accounts, unnecessary services, etc.

11

OWASP

Prevent Security Misconfiguration

Ensure web servers and application servers are hardened. PHP: Ensure allow_url_fopen and allow_url_include are both disabled in php.ini. Consider the use of Suhosin extension

Ensure web servers and application servers are hardened XML: Ensure common web attacks (remote XSLT transforms, hostile XPath queries, recursive DTDs, and so on) are protected by your XML stack. Do not hand craft XML documents or queries – use the XML layer.

12

OWASP

A6 Sensitive Data Exposure

The most common flaw is simply not encrypting sensitive data. When crypto is employed, weak key generation and management, and weak algorithm usage is common, particularly weak password hashing techniques. Browser weaknesses are very common and easy to detect, but hard to exploit on a large scale. External attackers have difficulty detecting server side flaws due to limited access and they are also usually hard to exploit.

13

OWASP

Prevent Sensitive Data Exposure

Use strong ciphers (AES 128 or better) with secure mode of operations (do not use ECB).

Use strong hashes (SHA 256 or better) with salts for passwords.

Protect keys more than any other asset. Mandate strong encrypted communications

between web and database servers and any other servers or administrative users.

Buy extended validation (EV) certificates for public web servers.

14

OWASP

A7 Missing Function Level Access Control Applications do not always protect

application functions properly. Sometimes, function level protection is managed via configuration, and the system is misconfigured. Sometimes, developers must include the proper code checks, and they forget.

Detecting such flaws is easy. The hardest part is identifying which pages (URLs) or functions exist to attack.

15

OWASP

Prevent Missing Function Level Access Control Ensure all non-web data is outside the web

root (logs, configuration, etc). Use octet byte streaming instead of

providing access to real files such as PDFs or CSVs or similar.

Ensure every page requires a role, even if it is "guest".

Validate role is sufficient to perform secured action.

16

OWASP

A8 Cross-Site Request Forgery (CSRF)

CSRF takes advantage the fact that most web apps allow attackers to predict all the details of a particular action.

Because browsers send credentials like session cookies automatically, attackers can create malicious web pages which generate forged requests that are indistinguishable from legitimate ones.

Detection of CSRF flaws is fairly easy via penetration testing or code analysis.

17

OWASP

Prevent CSRF

Pre-render: Validate user is authenticated Validate role is sufficient for this view Render: Send CSRF token. Set "secure" and "HttpOnly" flags for

session cookies.

CSRF is always possible if there is XSS, so make sure XSS is eliminated within your application.

18

OWASP

A9 Using Components with Known Vulnerabilities Virtually every application has these

issues because most development teams don’t focus on ensuring their components/libraries are up to date. In many cases, the developers don’t even know all the components they are using, never mind their versions. Component dependencies make things even worse.

19

OWASP

Prevent Using Components with Known Vulnerabilities Identify all components and the versions

you are using, including all dependencies. Monitor the security of these components

in public databases, project mailing lists, and security mailing lists, and keep them up to date.

Establish security policies governing component use, such as requiring certain software development practices, passing security tests, and acceptable licenses.

20

OWASP

A10 Unvalidated Redirects and Forwards Applications frequently redirect users to

other pages, or use internal forwards in a similar manner. Sometimes the target page is specified in an unvalidated parameter, allowing attackers to choose the destination page.

Detecting unchecked redirects is easy. Look for redirects where you can set the full URL. Unchecked forwards are harder, because they target internal pages.

21

OWASP

Prevent Unvalidated Redirects and Forwards Design the app without URL redirection

parameters. Obtain direct redirection parameter from

random indirect reference access map. (LR) Positive validation of redirection

parameter. (NR) Java – Do not forward() requests as

this prevents SSO access control mechanisms.

22

OWASP

Join OWASP and help to make the Web, make the World more secure!

Join a chapter Join a project Join the global community list Share the security knowledge

23