A presentation of OWASP's top 10 most common web application security flaws. The content in the slides is sourced from various sources listed in the references section.

1. OWASP
TOP 10 SECURITY RISKS & VULNERABILITIES

2. What is OWASP
 OWASP stands for the Open Web Application
Security Project, an online community that
produces articles, methodologies, documentation,
tools, and technologies in the field of web
application security

3. OWASP TOP 10
 OWASP Top 10 is the list of the 10 most common application vulnerabilities.
 It also shows their risks, impacts, and countermeasures.
 Updated every three to four years, the latest OWASP vulnerabilities list was
released in 2018.

4. Let’s dive into it!
1. Injection
2. Broken Authentication
3. Sensitive Data Exposure
4. XML External Entities (XXE)
5. Broken Access control
6. Security misconfigurations
7. Cross Site Scripting (XSS)
8. Insecure Deserialization
9. Using Components with known vulnerabilities
10. Insufficient logging and monitoring

5. 1. INJECTION
 Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when
untrusted data is sent to an interpreter as part of a command or query through a
form input or some other data submission to a web application.
 The attacker’s hostile data can trick the interpreter into executing unintended
commands or accessing data without proper authorization.

6. Types of SQL Injection
1) In-band SQLi (Classic) - The attacker uses the same channel of communication to
launch their attacks and to gather their results
a) Error-based SQLi - the attacker performs actions that cause the database to produce
error messages
b) Union-based SQLi - this technique takes advantage of the UNION SQL operator, which
fuses multiple select statements generated by the database to get a single HTTP
response

7. Types of SQL injection
2) Inferential SQLi (Blind) - The attacker sends data payloads to the server and observes
the response and behavior of the server to learn more about its structure
a) Boolean - that attacker sends a SQL query to the database prompting the application to
return a result. The result will vary depending on whether the query is true or false. Based on
the result, the information within the HTTP response will modify or stay unchanged. The
attacker can then work out if the message generated a true or false result.
b) Time-based - attacker sends a SQL query to the database, which makes the database wait
(for a period in seconds) before it can react. The attacker can see from the time the database
takes to respond, whether a query is true or false. Based on the result, an HTTP response will
be generated instantly or after a waiting period. The attacker can thus work out if the
message they used returned true or false, without relying on data from the database.

8. Types of SQL injection
3) Out-of-band SQLi - The attacker can only carry out this form of attack when certain
features are enabled on the database server used by the web application

9. SQL injection examples
http://www.estore.com/items/items.asp?itemid=999 or 1=1.
 since the statement 1 = 1 is always true, the query returns all of the product names and
descriptions in the database, even those that you may not be eligible to access
999 ‘ or 1=1’Enter item ID
SUBMIT

10. SQL injection examples
http://www.estore.com/items/iteams.asp?itemid=999; DROP TABLE Users
 As a result, the entire user database could be deleted.
999 ; DROP TABLE USERSEnter item ID
SUBMIT
Enter item ID

11. SQL injection: UNION SELECT example
http://www.estore.com/items/items.asp?itemid=999 UNION SELECT user-name, password FROM USERS
 this query combines the request for item 999’s name and description with another that
pulls names and passwords for every user in the database.
999 UNION SELECT user-name, password FROM USERS
SUBMIT
Enter item ID

12. Preventing SQL Injection
 Preventing injection requires keeping data separate from commands and queries.
 The preferred option is to use a safe API, which avoids the use of the interpreter
entirely or provides a parameterized interface, or migrate to use Object Relational
Mapping Tools (ORMs).

13. 2. BROKEN AUTHENTICATION
 Occurs when application functions related to authentication and session
management are often implemented incorrectly.
 This allows attackers to compromise passwords, keys, or session tokens, or to
exploit other implementation flaws to assume other users’ identities temporarily
or permanently.
 Example: Application session timeouts aren’t set properly. A user uses a public computer to access
an application. Instead of selecting “logout” the user simply closes the browser tab and walks away.
An attacker uses the same browser an hour later, and the user is still authenticated

14. Broken authentication vulnerabilities
 An app is vulnerable if it:
 Permits automated attacks such as credential stuffing, where the attacker has a list of
valid usernames and passwords.
 Permits brute force or other automated attacks.
 Permits default, weak, or well-known passwords, such as”Password1″ or “admin/admin.″
 Uses weak or ineffective credential recovery and forgot-password processes, such as
“knowledge-based answers,” which cannot be made safe.

15. Broken authentication vulnerabilities:
 Uses plain text, encrypted, or weakly hashed passwords.
 Has missing or ineffective multi-factor authentication.
 Exposes session IDs in the URL (e.g., URL rewriting).
 Eg: https://bank.com/user=1234 => https://bank.com/user=4321
 Does not rotate session IDs after successful login.
 Does not properly invalidate session IDs. User sessions or authentication tokens
(particularly single sign-on (SSO) tokens) aren’t properly invalidated during logout or a
period of inactivity.

16. Preventing broken authentication
 Where possible, implement multi-factor authentication to prevent automated,
credential stuffing, brute force, and stolen credential re-use attacks.
 Do not ship or deploy with any default credentials, particularly for admin users.
 Implement weak-password checks, such as testing new or changed passwords
against a list of the top 10000 worst passwords.
 Align password length, complexity and rotation policies with NIST 800-63 B’s
guidelines in section 5.1.1 for Memorized Secrets or other modern, evidence
based password policies.

17. Preventing broken authentication
 Ensure registration, credential recovery, and API pathways are hardened against
account enumeration attacks by using the same messages for all outcomes.
 Limit or increasingly delay failed login attempts. Log all failures and alert
administrators when credential stuffing, brute force, or other attacks are detected.
 Use a server-side, secure, built-in session manager that generates a new random
session ID with high entropy after login. Session IDs should not be in the URL, be
securely stored and invalidated after logout, idle, and absolute timeouts.

18. 3. SENSITIVE DATA EXPOSURE
 consists of compromising data that should have been protected.
Examples of Sensitive Data that requires protection:
1. Credentials e.g. usernames and passwords
2. Credit card numbers
3. Social Security Numbers
4. Medical information
5. Personally identifiable information (PII)
6. Other personal information

19. Types of sensitive data
 Stored data – data at rest
 Transmitted data – data that is transmitted internally between servers, or to web
browsers

20. Preventing sensitive data exposure
 Classify data processed, stored or transmitted by an application. Identify which
data is sensitive according to privacy laws, regulatory requirements, or business
needs.
 Apply controls as per the classification.
 Don’t store sensitive data unnecessarily. Discard it as soon as possible. Data that is
not retained cannot be stolen.
 Make sure to encrypt all sensitive data at rest.
 Ensure up-to-date and strong standard algorithms, protocols, and keys are in
place; use proper key management.

21. Preventing sensitive data exposure
 Encrypt all data in transit with secure protocols such as TLS with.
 Disable caching for response that contain sensitive data.
 Store passwords using strong adaptive and salted hashing functions with a work
factor (delay factor), such as Argon2, scrypt, bcrypt or PBKDF2.
 Verify independently the effectiveness of configuration and settings.

22. 4. XML EXTERNAL ENTITIES (XEE)
• XML External Entity attack is a type of attack against an application that parses
XML input.
• This attack occurs when XML input containing a reference to an external entity is
processed by a weakly configured XML parser

23. XML EXAMPLE
Shopping application
XXE Vulnerability
Server response

24. Preventing XML external entity attacks
 Whenever possible, use less complex data formats ,such as JSON, and avoid
serialization of sensitive data.
 Patch or upgrade all XML processors and libraries in use by the application or on
the underlying operating system.

25. 5. BROKEN ACCESS CONTROL
In website security, access control means putting a limit on what sections or pages
visitors can reach, depending on their needs.
 some examples of what we consider to be “access”:
1. Access to a hosting control / administrative panel
2. Access to a server via FTP / SFTP / SSH
3. Access to a website’s administrative panel
4. Access to other applications on your server
5. Access to a database

26. Broken access control examples
Scenario 1:
http://example.com/app/accountInfo?acct=notmyacct
An attacker simply modifies the ‘acct’ parameter in the browser to send whatever account
number they want. If not properly verified, the attacker can access any user’s account.
Scenario 2:
 An attacker simply force browses to target URLs. Admin rights are required for access
to the admin page.
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo

27. Reducing risks of broken access control
 Employ least privileged concepts – apply a role appropriate to the task and only for the amount of
time necessary to complete said task and no more.
 Get rid of accounts you don’t need or whose user no longer requires it.
 Audit your servers and websites – who is doing what, when, and why.
 If possible, apply multi-factor authentication to all your access points.
 Disable access points until they are needed in order to reduce your access windows.
 Remove unnecessary services off your server.
 Check applications that are externally accessible versus applications that are tied to your network.
 If you are developing a website, bear in mind that a production box should not be the place to
develop, test, or push updates without testing.

28. 6. SECURITY MISCONFIGURATION
Is often the result of using default configurations or displaying excessively verbose
errors
Examples
1. The app server admin console is automatically installed and not removed
2. Directory listing is not disabled on your server
3. App server configuration allows stack traces to be returned to users, potentially
exposing underlying flaws
4. App server comes with sample applications that are not removed from your
production server

29. 7. CROSS-SITE SCRIPTING
• Occur when web applications allow users to add custom code into a url path or
onto a website that will be seen by other users
• This vulnerability can be exploited to run malicious JavaScript code on a victim’s
browser
Types of XSS
1. Reflected
2. Stored
3. DOM

30. 8. INSECURE DESERIALIZATION
This threat targets the many web applications which frequently serialize and
deserialize data.
 The process of serialization is converting objects to byte strings.
 The process of deserialization is converting byte strings to objects.

31. 9. USING COMPONENTS WITH KNOWN
VULNERABILITIES
 Components, such as libraries, frameworks, and other software modules, run with
the same privileges as the application.
 If a vulnerable component is exploited, such an attack can facilitate serious data
loss or server takeover.
 Applications and APIs using components with known vulnerabilities may
undermine application defenses and enable various attacks and impacts.

32. An app is vulnerable if:
 If you do not know the versions of all components you use (both client-side and
server-side). This includes components you directly use as well as nested
dependencies.
 If software is vulnerable, unsupported, or out of date. This includes the OS,
web/application server, database management system (DBMS), applications, APIs
and all components, runtime environments, and libraries.
 If you do not scan for vulnerabilities regularly and subscribe to security bulletins
related to the components you use.

33. An app is vulnerable if:
 If you do not fix or upgrade the underlying platform, frameworks, and
dependencies in a risk-based, timely fashion. This commonly happens in
environments when patching is a monthly or quarterly task under change control,
which leaves organizations open to many days or months of unnecessary
exposure to fixed vulnerabilities.
 If software developers do not test the compatibility of updated, upgraded, or
patched libraries.

34. 10. INSUFFICIENT LOGGING AND MONITORING
Not having an efficient logging and monitoring process in place can increase the
damage of a website compromise.
Attackers rely on the lack of monitoring and timely response to achieve their goals
without being detected.

35. References
 https://owasp.org/www-project-top-ten/
 https://sucuri.net/guides/owasp-top-10-security-vulnerabilities-2020/
 https://www.imperva.com/learn/application-security/sql-injection-sqli/