What is OWASP?

History

Principles

OWASP Top 10

Example: XML External Entities (XXE)

Prevention

Proactive > Reactive

The Mind of an Attacker

The Juice Shop

OWASP ZAP

Takeaways​ / Q&A

The OWASP  (Open Web Application Security Project)

Foundation launched in 2001, becoming incorporated as a U.S. non-profit charity in 2004.

Principles:

Open: Everything at OWASP is radically transparent from the finances to the code.

Innovative: OWASP encourages and supports innovation and experiments for solutions to software security challenges.

Global: Anyone around the world is encouraged to participate in the OWASP community.

Integrity: The community is respectful, supportive, truthful, and vendor neutral

Ideologies and concepts

Platform agnostic

multi-departmental impact

Reputable source

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.

Threat Agent / Attack Vector

Almost any source of data can be an injection vector, environment variables, parameters, external and internal web services, and all types of users. Injection flaws occur when an attacker can send hostile data to an interpreter.

http://example.com/accountView?id=xxx
 

'or '1'='1

This changes the meaning of the query to return all the records from the accounts table. More dangerous attacks could modify or delete data, or even invoke stored procedures.

Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident. Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected.

One strategy for determining if you have sufficient monitoring is to examine the logs following penetration testing. The testers’ actions should be recorded sufficiently to understand what damages they may have inflicted.

Most successful attacks start with vulnerability probing. Allowing such probes to continue can raise the likelihood of successful exploit to nearly 100%. In 2016, identifying a breach took an average of 191 days – plenty of time for damage to be inflicted.

While it is easy to find already-written exploits for many known vulnerabilities, other vulnerabilities require concentrated effort to develop a custom exploit.

Prevalence of this issue is very widespread. Component-heavy development patterns can lead to development teams not even understanding which components they use in their application or API, much less keeping them up to date. Some scanners help in detection, but determining exploitability requires additional effort.

While some known vulnerabilities lead to only minor impacts, some of the largest breaches to date have relied on exploiting known vulnerabilities in components. Depending on the assets you are protecting, perhaps this risk should be at the top of the list.

Automated tools can detect and exploit all three forms of XSS, and there are freely available exploitation frameworks.

XSS is the second most prevalent issue in the OWASP Top 10, and is found in around two thirds of all applications.
Automated tools can find some XSS problems automatically, particularly in mature technologies such as PHP, J2EE / JSP, and ASP.NET.

The impact of XSS can be severe  with remote code execution on the victim’s browser, such as stealing credentials, sessions, or delivering malware to the victim.

Attackers will often attempt to exploit unpatched flaws or access default accounts, unused pages, unprotected files and directories, etc to gain unauthorized access or knowledge of the system.

Security misconfiguration can happen at any level of an application stack, including the network services, platform, web server, application server, database, frameworks, custom code, and pre-installed virtual machines, containers, or storage. Automated scanners are useful for detecting misconfigurations, use of default accounts or configurations, unnecessary services, legacy options, etc.

Such flaws frequently give attackers unauthorized access to some system data or functionality. Occasionally, such flaws result in a complete system compromise.

Access control is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks.

Access control weaknesses are common due to the lack of automated detection, and lack of effective functional testing by application developers.

The technical impact is attackers acting as users or administrators, or users using privileged functions, or creating, accessing, updating or deleting every record.

Attackers have access to hundreds of millions of valid username and password combinations for credential stuffing, default administrative account lists, automated brute force, and dictionary attack tools. Session management attacks are well understood, particularly in relation to unexpired session tokens.

Session management is the bedrock of authentication and access controls, and is present in all stateful applications.
Attackers can detect broken authentication using manual means and exploit them using automated tools with password lists and dictionary attacks.

Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations.

By default, many older XML processors allow specification of an external entity, a URI that is dereferenced and evaluated during XML processing.

These flaws can be used to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks.

The application accepts XML directly or XML uploads, especially from untrusted sources, or inserts untrusted data into XML documents, which is then parsed by an XML processor.

Any of the XML processors in the application or SOAP based web services has document type definitions (DTDs) enabled.

If the application uses SAML for identity processing within federated security or single sign on (SSO) purposes. SAML uses XML for identity assertions, and may be vulnerable.

Being vulnerable to XXE attacks likely means that the application is vulnerable to denial of service attacks including the Billion Laughs attack

<?xml version="1.0"?>
<!DOCTYPE lolz [
<!ENTITY lol "lol">

<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">

<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">

<!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
<!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
<!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
<!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
<!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
<!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">

]>
<lolz>&lol9;</lolz>

OWASP has created the "OWASP Juice Shop". This is a purposley insecure webapp that utilizes game theory to entice you to break in.

The Juice Shop is linked to a scoreboard that helps you keep track of your progress and leads you through the different challenges. There is no link to the scoreboard, it is one of the challenges. The first item in the tutorial tells us to look at the JS code within DevTools by hitting F12 or to just start guessing the url of the scoreboard.

Broken Authentication

Broken Access Control

Security Misconfiguration

Using Components with Known Vulnerabilities

Insufficient Logging & Monitoring

All devs should be aware

Internal Pen-testing should be part of CD/CI

Security policy templated from OWASP Top 10