What is OWASP?
OWASP stands for Open Web Application Security Project which 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.
trends 2017 -> 2021
Some definitions
What is Injection?
Injection flaws, such as SQL occur when untrusted data is sent to a web application as part of a command or query. The attacker’s payload can trick the web application into executing unintended commands or accessing data without proper authorization.
What is Broken Authentication?
Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.
What is Sensitive Data Exposure?
When 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.
What are XML External Entities?
Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.
What is Broken Access Control?
Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.
What is Security Misconfiguration?
Security Misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched/upgraded in a timely fashion.
What is Cross Site Scripting?
XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
What is Insecure Deserialization?
Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.
What is Using Components with Known Vulnerabilities?
Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.
What is Insufficient Logging and Monitoring?
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.
Some Mitigation
Let us discuss some basic recommendation points for common OWASP Top 10 vulnerabilities and some others (assuming that for almost all major vulnerabilities, OWASP has Wiki documents that can be used for Referencing):
SQL Injections
Injections (SQL): SQL injections exist when an application doesn’t sanitise user input before passing it into an SQL command. Here are a few recommendations:
- Sanitise user input and remove or encode special characters like ‘ “ - () # etc.
- Use whitelist filters, which means if a parameter is supposed to have integer values, do not allow non-numeric input. If it is an email field, allow alphanumerics, @ and .(dot)
- Use strong web application firewalls to make exploitation difficult
- Never run SQL server software (MySQL, MsSQL, etc.) as high privilege user such as ‘root’
- Use prepared statements for SQL queries instead of inserting user controlled input into SQL queries
- Remove default databases and accounts such as test, guest, admin, etc.
XSS
Cross Site Scripting (XSS): This happens when a user controlled input is reflected somewhere else in an HTML page and is not encoded/sanitised properly. This leads to an attacker being able to inject HTML code in the affected page. So, the fix is to make sure that any input which is taken from a user, while being written into an HTTP response must be cleaned first. So, the recommendations can be written as:
- Perform proper output encoding of special characters like < > “ ‘
- For example, before printing untrusted user-supplied data into an HTML response, convert special characters into HTML encoding (< > ” etc.) or URL encode them (%3C %3E %22 %27)
IDOR
Insecure Direct Object References (IDOR) + Rate Limiting (Brute forcing) flaws: This happens, when an application doesn’t check if a user who is requesting a resource actually is requesting data that he is supposed to view/edit. So, the recommendations can be:
- Sensitive information must only be accessible to authorised users
- Implement proper authentication and authorisation checks at every function to make sure the user requesting access to a resource whether to view or edit is his own data and no one else’s
- Implement proper Rate Limiting checks that disallows large number of requests from/to a single resource. For example, if from a single device, a single module like OTP check, password check, signup, etc. is being called 100 times in a single minute, it should be blocked
- Similarly, if an account’s password is being attempted to reset even from different devices, the account should be locked for a while
- Implement these checks on the basis of IP addresses and sessions
File Uploads
Arbitrary File Uploads: This happens when applications do not implement proper file type checking and allow uploading of files of different file formats. For example, a PHP file instead of a jpeg profile picture.
- Perform proper server-side validations on what kind of a file user is uploading
- Use white lists filters instead of black list filters. Example: in case of a resume upload feature, instead of banning PHP and .exe files, only allow .pdf, .doc and .docx files
- Rename the files using a code, so that the attacker cannot play around with file names
- Use static file hosting servers like CDNs and file clouds to store files instead of storing them on the application server itself
CSRF
Cross Site Request Forgery (CSRF): This happens, when an application accepts allows critical actions without any additional tokens like passwords and also allows HTTP requests without checking from where exactly they are coming from. To prevent CSRF, all critical actions must be password protected, CSRF token technology should be used to prevent and all requests must first check and make sure that the request is coming from the website itself and not some third party page. So, recommendations can be:
- Ask the user his password (temporary like OTP or permanent like login password) at every critical action like while deleting account, making a transaction, changing the password etc.
- Implement the concept of CSRF tokens which attach a unique hidden password to every user in every
<form>. Read the documentation related to the programming language and framework being used by your website. - Check the referer before carrying out actions. This means that any action on x.com should check that the HTTP referrer is
https://x.com/*and nothing else likehttps://x.com.hacker.com/
Known Vulns
Using components with known vulnerabilities: In this, the attacker finds that the server is using an older version of any software, plugin, theme, OS etc. and then uses publicly disclosed vulnerabilities of that specific version to exploit the server. So, the recommendations are:
- Upgrade to the latest version of Affected Software/theme/plugin/OS which means latest version number
- If upgrade is not possible for the time being, isolate the server from any other critical data and servers
Security Misconfigs
Security Misconfigurations: The category of security misconfigurations is rather wide and the recommendations are completely different for each misconfiguration but the concept is the same. For example, if a website is using an Apache Tomcat server and is configured with default credentials like tomcat:tomcat, the recommendations would contain the steps to change the password for apache tomcat and suggest to keep a strong alphanumeric password which is difficult to guess.
Cookies
Session and Cookie Flaws: Again these depend upon the exact flaw but below are some common good practices:
- Do not store critical information such as passwords in cookies
- Set relevant (based on business requirements) expiration time on sessions and cookies
- Disallow concurrent logins (login into the same account from multiple devices/locations)
- Make sure all cookies are HTTPs protected
- Destroy sessions and cookies properly once a user logs out
- Do not allow access to any resource without an authenticated and authorised cookie
- Cookies and session tokens should be at least 30-40 character long with alphanumerics, which are in no way related to the actual data they are referencing and should be impossible to guess
Client side validation flaws
Client Side validation flaws: These issues basically occur when an application does user input sanitisation only at the client side. Like taking the quantity of product to buy using non-editable text fields and + - buttons but once the request is generated using a proxy, you can pass negative or decimal values in quantity and on the server side no checks are in place. Hence, its patch is simple too.
- Implement all critical checks on server side code only
- Client-side checks must be treated as decoratives only
- All business logic must be implemented and checked on the server code.
- This includes user input, the flow of applications and even the URL/Modules a user is supposed to access or not