This document discusses security vulnerabilities and the OWASP Top 10. It provides background on why security is important when developing software, costs of data breaches, and an overview of the OWASP organization and Top 10 vulnerabilities. The Top 10 vulnerabilities discussed in more detail include injection, broken authentication and session management, cross-site scripting, insecure direct object references, security misconfiguration, sensitive data exposure, missing function level access control, cross-site request forgery, using components with known vulnerabilities, and unvalidated redirects/forwards. Examples are given for each vulnerability.

1. OWASP TOP 10
AND OTHER THREATS
SECURITY AWARENESS

2. Why is this important to us?
We develop software
rapidly, usually starting
with MVPs and
prototypes that later
scale. Better to include
security first, not find and
fix later.

3. Cost of data breaches
● You have a 1 in 960,000 chance to be struck by
lightning , but the odds of a data breach in
your enterprise are 1 in 4.
● Average cost in 2017: $3.62M USD.
● More than 60% of applications fail security
testing on first pass.
Source:https://securityintelligence.com/know-the-odds-the-cost-of-a-data-breach-in-2017/

4. What is OWASP and the OWASP Top 10?
The Open Web Application Security
Project (OWASP) is a non-profit
organization founded in 2001 and
dedicated to providing unbiased,
practical information about application
security. The OWASP Top 10
represents a broad consensus on the
most critical web application security
flaws.

5. The old world - hard on the
outside, soft on the inside
How we live now
The new world - harden at all
levels
..OR..mitigating against
squishiness at all levels.

6. Top 10 Vulnerabilities
1. Injection
2. Broken Authentication and Session Management (XSS)
3. Cross Site Scripting (XSS)
4. Insecure Direct Object References
5. Security Misconfiguration
6. Sensitive Data Exposure
7. Missing Function Level Access Control
8. Cross Site Request Forgery (CSRF)
9. Using Components with Known Vulnerabilities
10. Unvalidated Redirects and Forwards
This list is a blend of candidates for 2017 top ten and vulnerabilities from previous years:

7. What is it?
Code Injection is the general term for attack types which
consist of injecting code that is then
interpreted/executed by the application. This type of
attack exploits poor handling of untrusted data. These
types of attacks are usually made possible due to a lack
of proper input/output data validation, for example:
● allowed characters (standard regular expressions
classes or custom)
● data format
● amount of expected data.
Server-side (not client browser) input validation and
parameterized SQL are techniques to prevent against
this vulnerability.
Too much refactoring to parameterize or validate? There
is an API for that.
Example 1
If an application passes a parameter sent via a GET request
to the PHP include() function with no input validation, the
attacker may try to execute code other than what the
developer had in mind.
Example 2
A SQL statement is appended to text in a field that does not
validate input.. The forms a string that is concatenated into a
query executed against the database, e.g. ‘UPDATE Users
SET PASSWORD=”hacked”. Queries are not parameterized so
this update is performed and all users now have been
compromised.
See https://www.owasp.org/index.php/Code_Injection
1. Injection

8. What is it?
Are session management assets like user credentials and
session IDs properly protected? You may be vulnerable if:
● User authentication credentials aren’t protected when
stored using hashing or encryption.
● Credentials can be guessed or overwritten through
weak account management functions (e.g., account
creation, change password, recover password, weak
session IDs).
● Session IDs are exposed in the URL (e.g., URL
rewriting).
● Session IDs are vulnerable to session fixation attacks.
● Session IDs don’t timeout, or user sessions or
authentication tokens, particularly single sign-on (SSO)
tokens, aren’t properly invalidated during logout.
● Session IDs aren’t rotated after successful login.
Passwords, session IDs, and other credentials are sent
over unencrypted connections.
● Cookie values easy to spoof.
Example 1
Airline reservations application supports URL rewriting, putting session
IDs in the URL:
http://example.com/sale/saleitems?sessionid=268544541&dest=Hawaii
An authenticated user of the site wants to let his friends know about the
sale. He e-mails the above link without knowing he is also giving away his
session ID. When his friends use the link they will use his session and
credit card.
Example 2
Application’s timeouts aren’t set properly. User uses a public computer to
access site. Instead of selecting “logout” the user simply closes the
browser tab and walks away. Attacker uses the same browser an hour
later, and that browser is still authenticated.
Example 3
Insider or external attacker gains access to the system’s password
database. User passwords are not properly hashed, exposing every user
password to the attacker.
See
https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_an
d_Session_Management
2. Broken Authentication and Session Management

9. What is it?
Cross-Site Scripting (XSS) attacks occur when:
● Data enters a Web application through an
untrusted source, most frequently a web
request.
● The data is included in dynamic content that is
sent to a web user without being validated for
malicious content. For example, a site allows
HTML in text fields but does not scrub <script>
tags.
The malicious content sent to the web browser often
takes the form of a segment of JavaScript, but may also
include HTML, Flash, or any other type of code that the
browser may execute. The variety of attacks based on
XSS is almost limitless, but they commonly include
transmitting private data, like cookies or other session
information, to the attacker, redirecting the victim to
web content controlled by the attacker, or performing
other malicious operations on the user's machine under
the guise of the vulnerable site.
Example 1
The following JSP code segment reads an employee ID, eid, from an HTTP
request and displays it to the user.
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
The code in this example operates correctly if eid contains only standard
alphanumeric text. If eid has a value that includes meta-characters or source
code, then the code will be executed by the web browser as it displays the
HTTP response.
Example 2
The following JSP code segment queries a database for an employee with a
given ID and prints the corresponding employee's name.
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
%>
Employee Name: <%= name %>
See https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
3. Cross-Site Scripting (XSS)

10. What is it?
Insecure Direct Object References occur when an application
provides direct access to objects based on user-supplied
input. As a result of this vulnerability attackers can bypass
authorization and access resources in the system directly, for
example database records or files.
Insecure Direct Object References allow attackers to bypass
authorization and access resources directly by modifying the
value of a parameter used to directly point to an object. Such
resources can be database entries belonging to other users,
files in the system, and more. This is caused by the fact that
the application takes user supplied input and uses it to retrieve
an object without performing sufficient authorization checks.
Example 1
The value of a parameter is used directly to retrieve a database
record:
http://foo.bar/somepage?invoice=12345
Example 2
The value of a parameter is used directly to perform an
operation in the system:
http://foo.bar/changepassword?user=someuser
Example 3
The value of a parameter is used directly to retrieve a file
system resource:
http://foo.bar/showImage?img=img00011
Example 4
The value of a parameter is used directly to access application
functionality:
http://foo.bar/accessPage?menuitem=12
See
https://www.owasp.org/index.php/Testing_for_Insecure_Direc
t_Object_References_(OTG-AUTHZ-004)
4. Insecure Direct Object References

11. What is it?
Good security requires having a secure configuration defined and
deployed for the application, frameworks, application server, web
server, database server, platform, etc. Secure settings should be
defined, implemented, and maintained, as defaults are often insecure.
Additionally, software should be kept up to date.
● Is any of your software out of date? This software includes the
OS, Web/App Server, DBMS, applications, APIs, and all
components and libraries.
● Are any unnecessary features enabled or installed (e.g., ports,
services, pages, accounts, privileges)?
● Are default accounts and their passwords still enabled and
unchanged?
● Does your error handling reveal stack traces or other overly
informative error messages to users?
● Are the security settings in your application servers, application
frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases,
etc. not set to secure values?
Without a concerted, repeatable application security configuration
process, systems are at a higher risk.
Example 1
The app server admin console is automatically installed and not
removed. Default accounts aren’t changed. Attacker discovers
the standard admin pages are on your server, logs in with
default passwords, and takes over.
Example 2
Directory listing is not disabled on your web server. An attacker
discovers they can simply list directories to find any file. The
attacker finds and downloads all your compiled Java classes,
which they decompile and reverse engineer to get all your
custom code. Attacker then finds a serious access control flaw
in your application.
Example 3
App server configuration allows stack traces to be returned to
users, potentially exposing underlying flaws such as framework
versions that are known to be vulnerable.
Example 4
App server comes with sample applications that are not
removed from your production server. These sample
applications have well known security flaws attackers can use
to compromise your server.
See
https://www.owasp.org/index.php/Top_10_2017-A5-Security_
Misconfiguration
5. Security Misconfiguration

12. What is it?
Many web applications and APIs do not properly protect sensitive data,
such as financial, healthcare, and PII. Attackers may steal or modify such
weakly protected data to conduct credit card fraud, identity theft, or
other crimes. Sensitive data deserves extra protection such as
encryption at rest or in transit, as well as special precautions when
exchanged with the browser.
The first thing you have to determine is which data is sensitive enough to
require extra protection. For example, passwords, credit card numbers,
health records, and personal information should be protected. For all
such data:
● Is any of this data stored in clear text long term, including
backups of this data?
● Is any of this data transmitted in clear text, internally or
externally? Internet traffic is especially dangerous.
● Are any old / weak cryptographic algorithms used?
● Are weak crypto keys generated, or is proper key management or
rotation missing?
● Are any browser security directives or headers missing when
sensitive data is provided by / sent to the browser?
Example 1
An application encrypts credit card numbers in a database
using automatic database encryption. However, this data is
automatically decrypted when retrieved, allowing an SQL
injection flaw to retrieve credit card numbers in clear text.
Alternatives include not storing credit card numbers, using
tokenization, or using public key encryption.
Example 2
A site simply doesn’t use TLS for all authenticated pages. An
attacker simply monitors network traffic (like an open wireless
network), and steals the user’s session cookie. The attacker then
replays this cookie and hijacks the user’s session, accessing the
user’s private data.
Example 3
The password database uses unsalted hashes to store
everyone’s passwords. A file upload flaw allows an attacker to
retrieve the password database. All of the unsalted hashes can
be exposed with a rainbow table of precalculated hashes.
See
https://www.owasp.org/index.php/Top_10_2017-A6-Sensitive
_Data_Exposure
6. Sensitive Data Exposure

13. What is it?
Most web applications verify function level access rights before making
that functionality visible in the UI. However, applications need to perform
the same access control checks on the server when each function is
accessed. If requests are not verified, attackers will be able to forge
requests in order to access functionality without proper authorization.
● Does the UI show navigation to unauthorized functions?
● Are server side authentication or authorization checks missing?
● Are server side checks done that solely rely on information provided
by the attacker?
Using a proxy, browse your application with a privileged role. Then revisit
restricted pages using a less privileged role. If the server responses are
alike, you're probably vulnerable. Some testing proxies directly support this
type of analysis.
You can also check the access control implementation in the code. Try
following a single privileged request through the code and verifying the
authorization pattern. Then search the codebase to find where that pattern
is not being followed. Automated tools are unlikely to find these problems.
Example 1
The attacker simply force browses to target URLs. The
following URLs require authentication. Admin rights are also
required for access to the admin_getappInfo page.
http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo
If an unauthenticated user can access either page, that’s a flaw.
If an authenticated, non-admin, user is allowed to access the
admin_getappInfo page, this is also a flaw, and may lead the
attacker to more improperly protected admin pages.
Example 2
A page provides an 'action' parameter to specify the function
being invoked, and different actions require different roles. If
these roles aren’t enforced, that’s a flaw.
See
https://www.owasp.org/index.php/Top_10_2013-A7-Missing_F
unction_Level_Access_Control
7. Missing Function Level Access Control

14. What is it?
A CSRF attack forces a logged-on victim’s browser to send a forged
HTTP request, including the victim’s session cookie and any other
automatically included authentication information, to a vulnerable web
application. This allows the attacker to force the victim’s browser to
generate requests the vulnerable application thinks are legitimate
requests from the victim. To check whether an application is vulnerable,
see if any links and forms lack an unpredictable CSRF token. Without
such a token, attackers can forge malicious requests. An alternate
defense is to require the user to prove they intended to submit the
request, either through re authentication, or some other proof they are a
real user (e.g., a CAPTCHA).
Focus on the links and forms that invoke state-changing functions, since
those are the most important CSRF targets.
You should check multistep transactions, as they are not inherently
immune. Attackers can easily forge a series of requests by using multiple
tags or possibly JavaScript.
Note that session cookies, source IP addresses, and other information
automatically sent by the browser don’t provide any defense against
CSRF since this information is also included in forged requests.
Example
The application allows a user to submit a state changing
request that does not include anything secret. For example:
http://example.com/app/transferFunds?amount=1500&destin
ationAccount=4673243243
So, the attacker constructs a request that will transfer money
from the victim’s account to the attacker’s account, and then
embeds this attack in an image request or iframe stored on
various sites under the attacker’s control:
<img
src="http://example.com/app/transferFunds?amount=1500&de
stinationAccount=attackersAcct#" width="0" height="0" />
If the victim visits any of the attacker’s sites while already
authenticated to example.com, these forged requests will
automatically include the user’s session info, authorizing the
attacker’s request.
See
https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Sit
e_Request_Forgery_(CSRF)
8. Cross Site Request Forgery (CSRF)

15. What is it?
Components, such as libraries, frameworks, and other software modules,
almost always run with full privileges. If a vulnerable component is exploited,
such an attack can facilitate serious data loss or server takeover. Applications
using components with known vulnerabilities may undermine application
defenses and enable a range of possible attacks and impacts.
It should be easy to figure out if you are currently using any vulnerable
components or libraries. Vulnerability reports for commercial or open source
software do not always specify exactly which versions of a component are
vulnerable in a standard, searchable way. Further, not all libraries use an
understandable version numbering system. Worst of all, not all vulnerabilities
are reported to a central clearinghouse that is easy to search, although sites
like CVE and NVD are becoming easier to search.
Determining if you are vulnerable requires searching these databases, as well
as keeping abreast of project mailing lists and announcements for anything
that might be a vulnerability. If one of your components does have a
vulnerability, you should carefully evaluate whether you are actually
vulnerable by checking to see if your code uses the part of the component
with the vulnerability and whether the flaw could result in an impact you care
about.
Example
Component vulnerabilities can cause almost any type of risk
imaginable, ranging from the trivial to sophisticated malware
designed to target a specific organization. Components almost
always run with the full privilege of the application, so flaws in
any component can be serious, The following two vulnerable
components were downloaded 22m times in 2011.:
Apache CXF Authentication Bypass – By failing to provide an
identity token, attackers could invoke any web service with full
permission. (Apache CXF is a services framework, not to be
confused with the Apache Application Server.)
Spring Remote Code Execution – Abuse of the Expression
Language implementation in Spring allowed attackers to
execute arbitrary code, effectively taking over the server.
Every application using either of these vulnerable libraries is
vulnerable to attack as both of these components are directly
accessible by application users. Other vulnerable libraries, used
deeper in an application, may be harder to exploit.
See
https://www.owasp.org/index.php/Top_10_2013-A9-Using_Co
mponents_with_Known_Vulnerabilities
9. Using Components with Known Vulnerabilities

16. What is it?
Modern applications often involve rich client applications and APIs, such
as JavaScript in the browser and mobile apps, that connect to an API of
some kind (SOAP/XML, REST/JSON, RPC, GWT, etc.). These APIs are
often unprotected and contain numerous vulnerabilities.
Testing your APIs for vulnerabilities should be similar to testing the rest of
your application for vulnerabilities. All the different types of injection,
authentication, access control, encryption, configuration, and other issues
can exist in APIs just as in a traditional application.
However, because APIs are designed for use by programs (not humans)
they frequently lack a UI and also use complex protocols and complex
data structures. These factors can make security testing difficult. The use
of widely-used formats can help, such as Swagger (OpenAPI), REST,
JSON, and XML. Some frameworks like GWT and some RPC
implementations use custom formats. Some applications and APIs create
their own protocol and data formats, like WebSockets. The breadth and
complexity of APIs make it difficult to automate effective security testing,
possibly leading to a false sense of security.
Example 1
An attacker embeds a redirecting URL on a page or email to a
weak site that allows redirects, for example
www.afip.gob.ar/main.jsp?DNI=101010101&...dest=www.soymalito.com
Example 2
Imagine a mobile banking app that connects to an XML API at the
bank for account information and performing transactions. The
attacker reverse engineers the app and discovers that the user
account number is passed as part of the authentication request to
the server along with the username and password. The attacker
sends legitimate credentials, but another user’s account number,
gaining full access to the other user’s account.
Example 3
Imagine an API that accepts JSON messages that contain a
“transactionid” field. The API parses out this “transactionid” value
as a string and concatenates it into a SQL query, without escaping
or parameterizing it.
See https://www.owasp.org/index.php/Top_10_2013-Top_10
10. Unvalidated Redirects and Forwards

17. Common Attacks
Advanced Persistent Threat (APT)
An advanced persistent threat is characterized by more sophisticated and concentrated efforts by
coordinated attackers focused on a single target. The aim is to infiltrate a sensitive system, remain
undetected for as long as possible, and leave few traces of their success. For these reasons, APTs have
become a favorite approach for those who aim to conduct cyber, corporate, and intelligence espionage.
Source: https://www.recordedfuture.com/cyber-threat-landscape-basics/

18. Distributed Denial of Service (DDoS)
DDoS attacks allow hackers to knock off its victims rather than steal information. Although this attack
is less technically challenging when compared to others, its effectiveness should not be
underestimated. DDoS attacks typically consist of flooding the network with packets of huge
amounts of data, thus reaching its limits. As a result, legitimate requests are lost or at least the
service becomes too slow to work with.
Source: https://www.recordedfuture.com/cyber-threat-landscape-basics/

19. Cross-Platform Malware (CPM)
Malware is no longer exclusive for Windows operating systems only. The economic incentive to build
cross-platform malware for cyber criminals rises with the growing number of systems using different
operating systems such as iOS. This would inevitably result in an increased number of CPM attacks
Source: https://www.recordedfuture.com/cyber-threat-landscape-basics/

20. Metamorphic and Polymorphic Malware
This category of malware keeps changing its code so each of its succeeding versions is different than the
previous one. Metamorphic and polymorphic malware pose the single biggest threat to organizations
across the world because it easily evades detection and conventional anti-viruses programs. It’s worth
noting polymorphic malware is more difficult to write since it requires complicated techniques like
register renaming, code permutation, code expansion, code shrinking, and garbage code insertion.
However, that’s rarely an issue for larger entities comprising of dedicated and well-supported hackers.
.
Source: https://www.recordedfuture.com/cyber-threat-landscape-basics/

21. Phishing (and Spear Phishing)
This vector generally operates via email, and the idea of email is based in the principle of non-exclusive
communication, which essentially means it allows anyone to contact anyone else (and vice-versa)
regardless of who they are. While people would generally expect to be contacted by those who are
authorized, most of them are unlikely to filter out communicants in the first instance of outreach because
doing so would destroy the whole purpose of email. This also may lead to Social Engineering type
hacks, which are basically confidence games to gain physical access to resources.
.
Source: https://www.recordedfuture.com/cyber-threat-landscape-basics/

22. Resources
● https://www.owasp.org/
The place to start.
● https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project
A purposefully vulnerable site project, useful for practice and awareness.
● http://codecurmudgeon.com/
Cool site with lists of shame.
● https://plugins.jetbrains.com/plugin/3847?pr=idea
FindBugs – static code scanner w/ IntelliJ plugin
● https://github.com/amngibson
Gems to use to run vulnerability tests against the infrastructure in Test, Stage, and Prod.
Post code checkin / .WAR compiled
● https://github.com/F-Secure/mittn
Security testing tools – Burp Suite, TLS config scanning, API fuzzing
● http://w3af.org/
w3af is a Web Application Attack and Audit Framework. The project’s goal is to create a
framework to help you secure your web applications by finding and exploiting all web
application vulnerabilities.
● http://sourceforge.net/projects/dirbuster/
DirBuster - DirBuster is a multi threaded java application designed to brute force
directories and files names on web/application servers.
● https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Pen testing tool for finding vulnerabilities in web applications.

23. Thanks!
Any questions?