Introduction to Owasp top 10 2017

1. OWASP Top 10
Internship Program

2. OWASP Top 10
• Open Web Application Security Project (OWASP) is non-profit entity and
an open community dedicated to enabling organizations to develop,
purchase, and maintain applications and APIs that can be trusted.
• OWASP published the 5th revision of their popular OWASP Top 10 list in
November 2017. The list contains the ten most critical security
vulnerabilities that threaten modern web applications
• OWASP Top 10 has been revised several times to reflect changes in the
way developers protect their web applications, and the methods attackers
use to target them.

3. 1: Injection
• Injection is most common security vulnerabilities.
• Injection flaws such as SQL, OS, and LDAP injection, occur
when untrusted data is sent to an interpreter as part of a
command or query. The attacker’s hostile data can trick the
interpreter into executing unintended commands or accessing
data without proper authorization.
Examples:
• SQL : writing different SQL commands on the username field
(SELECT * from table)
• OS: executing a router’s operating system's built-in ping
command with the hostname the user supplied, potentially
opening a security flaw.

4. Prevention
• Using Query parameterization which separate
statement from any kind of parameters.
• Validate user input , preventing unnecessary
symbols ( example * on username field)
• Limiting maximum information on the
database to be fetched.
• Building web app using proper control.
• Using web application firewall

5. 2: Broken Authentication
• Authentication in web applications is mostly
used to control users' access to specific
information.
• The most common security risks related to
authentication and session management are:
password theft, stealing session tokens and
impersonating legitimate users.

6. Broken Authentication allows users (bad users)
getting into web apps without proper credential.
The attacker may use:
• Credential stuffing: known usernames and
passwords.
• Automated attacks: random usernames and
passwords.
• Default username & passwords: like Username
Admin and Password Admin
• Social engineering: by tricking the victim.

7. Prevention
• Multifactor authentication: using multiple
authentications like biometrics, tokens and fingerprint
verification in addition to simple password.
• Password checking: checking password with in
database with top 10,000 passwords on the internet
and informing the user.
• recommend users to create strong passwords.
• Limit failed login
• Creating new session on the server side
• Using web application firewall

8. 3: Sensitive Data Exposure
• Sensitive data stored in databases (or anywhere else)
should be well protected.
• Credit card details, social security numbers and other
sensitive customer details should be encrypted at rest
when stored in a database, even if they are not directly
accessible through a web application.
• The same applies for sensitive data that is transmitted
to and from the web application, such as credentials or
payment details. Such information should be also be
transmitted over a secure and encrypted layer.

9. Prevention
• Encrypting all pages with sensitive data using strong
cipher (TLS, SSL)
• Classify data and apply control to the sensitive data
separately.
• Encrypted data at rest when stored in a database, even
if they are not directly accessible through a web
application.
• Avoid storing sensitive data unless it is absolutely
necessary.
• Avoiding file upload flow
• Using web application firewall

10. 4: XML External Entities (XEE)
• XML gives you a way to define your own entities in order to make
coding and configuration easier. An example (in an XML file) where
this is necessary is in a customizable configuration file in a web
application.
• XML Entities are like variables: they will expand to a defined value
once they are processed by the XML parser.
• However: there is one problem. When it is possible to pass XML
documents to a parser that supports external entities, attackers can
retrieve content from a website behind a firewall, issue requests to
certain services, and even disclose the content of files stored on the
server. Because entities can be referenced within entity definitions.
• attackers can craft an XML document that contains only 10 entities,
but that will eventually expand to a billion entities once it is parsed.
This is also known as the 'Billion Laughs Attack'.

11. Prevention
• Disable XEE completely or partially per parsor.
• Implement server side input validation.
• Using source code analysis tools (SCAST)
• Using Dynamic application security testing
(DAST)
• Using web application firewall.

12. 5: Broken Access Control
• Access Control is simply the process of granting and
denying access to a user.
• Different roles exits in different web app, these roles will
have different level of access. Example Admin and normal
user.
• Broken Access Control refers to restrictions that are not
properly enforced. It occurs for example when
authenticated users without administrative authority can
create new administrator accounts.
• A common example of such vulnerability is an admin panel
that relies heavily on JavaScript to execute certain actions,
such as the creation of an admin account.

13. Prevention
• Enforcing to trusted server side code.
• Doing a lot of manual testing before publishing the web
application.
• Deny everything by default, and only give access to who
need to use it.
• Implement access control once and reuse it across the web
application.
• Logging failures and alerting admins whenever happens
• Least privilege: giving the minimum extent they need to do
the job or function and beyond that only giving access for
the minimum amount of time they need to do the job.
• Using web application firewall.

14. 6: Security Misconfiguration
Web application security is not just about secure
web application coding. To ensure the security
of a web application, it is also important to:
• secure the configuration of the web server,
• secure the operating system of the web server.
• ensure that the server is always updated with the
latest security patches.
The same applies for the web frameworks used on the
web server, such as PHP and NET, Database servers like
oracles.

15. Prevention
• Check default configuration and turn off ports and
Delete features we don’t use. Default accounts
example username: Admin and password: Admin
• Don’t overshare information. Example: don’t project
any information on error page , like disclosure of
software versions. This may allow attackers to get
vulnerabilities for your software easily.
• Update softwares (example apache, oracle)with latest
security patches regularly.
• Use automated scanning capabilities.

16. 7: Cross-site Scripting (XSS)
• A cross-site scripting (XSS) vulnerability allows hackers to inject
malicious client-side script, in a website or web application, that is
later executed by the victims. Typically, cross-site scripting attacks
are used to bypass access controls and to impersonate legitimate
users, such as the web application administrator.
• Attackers sends code they want your browser to execute in order
to send them your secret (valuable) staff.
• Attackers may try to steal cookies by sending
post(<script>………….</script>) to the web application to get the
cookies of the victim by making the victim send it to the attacker.

17. Prevention
• Using latest and modern browsers and update
regularly, since better browsers have
improved detection of scripts with in HTML,
on the victims browser.
• When building web application, we need to
separate untrusted data from Active browser
content.

18. 8: Insecure Deserialization
• Insecure deserialization is the process of
changing byte streams (which were created by
serialization by saving and persisting the state of
the object) in to the original object.
• During this process , the attacker can modify the
byte stream, When it is deserialized, Attack
happens.
• The malicious attacker (invalidated user) can give
himself Admin role through Insecure
deserialization.

19. Prevention
• not to accept serialized objects from untrusted
sources.
• Isolating and running code that deserializes in
low privilege environments when possible.
• Logging deserialization exceptions and failures,
such as where the incoming type is not the
expected type, or the deserialization throws
exceptions.
• Restricting or monitoring incoming and outgoing
network connectivity from containers or servers
that deserialize.

20. 9: Using Components with Known
Vulnerabilities
• successful attacks happen When the attacker
exploited a known vulnerability in an outdated
software that was still being used.
• attacks happen When Administrators fail to
regularly update all of the software used on
their web servers and by web applications
with the latest, most secure and most stable
versions.

21. Prevention
• Update the software immediately, whenever
updates available.
• Plan for the known components.
• Monitor, patch, and configure the software
regularly.

22. 10: Insufficient Logging and
Monitoring
• Insufficient Logging and Monitoring refers to
the inability to log and detect hacking
attempts and breaches.
• Statistics from 2016 show that, on average, it
took an organization 191 days to detect a data
breach! It is possible to reduce this time
greatly, and prevent breaches before they
happen, if sufficient logging and monitoring
take place.

23. Prevention
• Logging every failed login , warning, error
messages etc.
• Log files must not contain information, if
accessed by attackers
• Make it sufficient content, to help us find out
pattern of failed logins. Example when someone
trying dictionary attack.
• Storing log files in good formats
• Integrity control (checking) on log file.
• Having response plan.