Introduction to
Who am I?
Gunnard Engebreth
@gunnard
IG: gunnarde
gunnard@gmail.com
Overview:
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
History:
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
OWASP Top 10
- The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks to web applications.
Ideologies and concepts
Platform agnostic
multi-departmental impact
Reputable source
OWASP Top 10
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.
OWASP Top 10
Security Weakness
Injection flaws are very prevalent, particularly in legacy code. Injection vulnerabilities are often found in SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries.
Injection flaws are easy to discover when examining code. Scanners and fuzzers can help attackers find injection flaws.
OWASP Top 10
Injection Example:
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.
OWASP Top 10
Insufficient Logging & Monitoring
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.
OWASP Top 10
Using Components with Known Vulnerabilities
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.
OWASP Top 10
Cross-Site Scripting (XSS)
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.
OWASP Top 10
Security Misconfiguration
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.
OWASP Top 10
Broken Access Control
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.
OWASP Top 10
Broken Authentication
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.
OWASP Top 10
Rock You
In December 2009, the company experienced a data breach resulting in the exposure of over 32 million user accounts. The company used an unencrypted database to store user account data, including plaintext passwords (as opposed to password hashes) for its service, as well as passwords to connected accounts at partner sites (including Facebook, Myspace, and webmail services). RockYou would also e-mail the password unencrypted to the user during account recovery. They also did not allow using special characters in the passwords. The hackers used a 10-year-old SQL vulnerability to gain access to the database. The company took days to notify users after the incident, and initially incorrectly reported that the breach only affected older applications when it actually affected all RockYou users.
OWASP Top 10
XML External Entities (XXE)
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.
OWASP Top 10
XML External Entities (XXE)
Is the Application Vulnerable?
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
OWASP Top 10
XML External Entities (XXE)
The Billion Laughs attack is a denial-of-service attack that targets XML parsers.
- XML Bomb
- the exponential entity expansion attack
OWASP Top 10
<?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 Top 10
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<stockCheck><productId>&xxe;</productId></stockCheck>
The Mind of an Attacker
The Mind of an Attacker
OWASP has created the "OWASP Juice Shop". This is a purposley insecure webapp that utilizes game theory to entice you to break in.
OWASP Juice Shop
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.
OWASP Juice Shop
OWASP Juice Shop
OWASP Juice Shop
OWASP Juice Shop
OWASP Juice Shop
Broken Authentication
Broken Access Control
Security Misconfiguration
Using Components with Known Vulnerabilities
Insufficient Logging & Monitoring
OWASP ZAP
The ZED Attack Proxy or ZAP is another flagship project that "can help you automatically find security vulnerabilities in your web applications while you are developing and testing your applications."
OWASP ZAP
OWASP ZAP
OWASP ZAP
OWASP and WordPress
Addressing A1: Injection in WordPress
SQL Injection is a technical application vulnerability that is typically caused by lack of sanitation of user input. By exploiting it, malicious hackers can gain access to data in the WordPress database.
The WordPress core team typically fixes injection vulnerabilities within a few days. The same applies for most of the WordPress plugins developers. Hence why it is important to always use well maintained plugins that are developed by responsive developers.
The only way you can ensure your WordPress core, plugins and themes are not vulnerable to this type of vulnerability is by keeping all your software up to date. Always install all the security patches the developers release.
OWASP and WordPress
Addressing A2: Broken Authentication in WordPress
These type of security flaws are also technical vulnerabilities. These vulnerabilities are the result of a broken design of the web application, lack of planning. Attackers can exploit broken authentication issues to access sensitive data.
Only developers can address these issues. As long as you use the latest version of WordPress core and plugins, your website will not be prone to such vulnerabilities. Of course, assuming you always use well maintained plugins.
Though since we are talking about authentication, it is worth reminding you to implement two-factor authentication on your WordPress website.
OWASP and WordPress
Addressing A4: XML External Entities (XXE) in WordPress
This is a technical software vulnerability. This happens when the application incorrectly handles XML files and data. An out of the box WordPress install does not deal much with remote XML files, though you might use plugins that do.
To ensure your WordPress website is not vulnerable to such type of vulnerability use the latest version of WordPress core, plugin and other software. Always use plugins that are maintained. Consider changing any plugin that you use that has not been updated in more than a year.
OWASP and WordPress
Addressing A6: Security Misconfiguration in WordPress Websites
Security misconfigurations are very common in WordPress websites. Unpatched software and exploitation of defaults are two of the most common successful attacks on WordPress websites. In the last few years the WordPress core team has done a lot to help users address such issues. For example WordPress no longer has a default admin username, which was the culprit of many WordPress hacks.
To ensure your WordPress website does not have any security misconfigurations change all the defaults. This applies to WordPress, plugins and any other software & device you use. For example if a plugin has a default set of credentials, does not password protect sensitive data, or stores it in a default location, configure strong authentication and change default paths.
OWASP and WordPress
Addressing : Insufficient Logging & Monitoring on WordPress
Logging and monitoring is vital for the security of your WordPress website and multi site network. WordPress activity logs also help you better manage your website, identify suspicious behavior before it becomes a problem, ensure user productivity and much more.
OWASP and WordPress
Addressing : Insufficient Logging & Monitoring on WordPress
Logging and monitoring is vital for the security of your WordPress website and multi site network. WordPress activity logs also help you better manage your website, identify suspicious behavior before it becomes a problem, ensure user productivity and much more.
OWASP and WordPress
WordPress security can be complex, especially when dealing with large setups. Though getting started and covering the basics is not that difficult, as this article highlights. You can have an OWASP Top 10 compliant WordPress website by taking care of these basics:
- Use the latest version of the WordPress core, plugins and themes,
- Ensure you change all of the defaults in your WordPress core and plugins,
- Enforce strong password policies,
- Enable 2FA with a two-factor authentication WordPress plugin,
- Use WordPress users and roles appropriately,
- Keep a record of everything that happens on your website in a WordPress activity log.
Conclusion
All devs should be aware
Internal Pen-testing should be part of CD/CI
- Zap
- Linpeas
- NMAP
Security policy templated from OWASP Top 10
Thank You
gunnard@gmail.com
@gunnard
ig: gunnarde
Introduction to OWASP [Wordpress]
By Gunnard Engebreth
Introduction to OWASP [Wordpress]
- 183