Sergey Kochergan is QA Engineer at Luxoft with extensive experience in software engineering and security field. As an independent consultant, he has provided strategic expertise to business clients with frameworks for SCADA security policy, organazied hackatons and ctf events. Sergey was involved into R&D projects of System Design for SDR communication hardware, network forensics with IDS. In this lecture Sergey will tell the audience about Security in general, will make overview of nowadays Web Testing Environment and also will present his vision of Risk Rating Methodology and Vulnerability Patterns. For our next events join us: http://www.meetup.com/Kyiv-Dev-Meetup-SmartMonday/ https://www.facebook.com/braindevkyiv

1. Copyright © 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
Sergey Kochergan
Luxoft
22 May 2016

2. OWASP 2
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

3. 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

4. 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

5. 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

6. 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

7. 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

8. OWASP
Prevent XSS
Render:
Set correct content type and character set
Output 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. 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

22. 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

23. 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