# Owasp Top 10 - 101 ###### tags: `web security` `cyber security` `owasp` ## 1. Injection Occurs when user controlled input is interpreted as actual commands or parameters by the application. Injection attacks depend on the tech used and how the commands are interpreted: * SQL injection: occurs when user controlled input is passed to SQL queries * Command injection: occurs when user input is passed to system commands. This allows arbitrary execution of system commands on a web server. This allows for **data exfiltration, unauthorized access, modification and deletion of information.** In the case of command injection, more attacks can be carried out on the infrastructure linked to the compromised server. To prevent this ensure user input is not interpreted as queries or commands. You can do this by: * Use of an allow list: input is compared to a list of safe input / characters, if it is marked as safe it is processed, else it is discarded and an error is thrown. * Stripping input: removing dangerous characters before they are processed. There are libraries to do this for you :) ### OS Command Injection When server side code makes a system call on the hosting machine. This is a web vulnerability allowing an attacker to make a system call through the web app to execute OS commands on the server, usually with the permissions of the account the server is running as. If a reverse shell is established, that's game set match - hacker You could use [these reverse shells](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md) * **Blind command injection**: system command made to the server **does not** return the response to the user in the HTML document. * **Active command injection**: system command made to the server **will return** the response to the user. Some useful commands when you have a reverse shell are: | Linux | Windows | | ----------------- |:----------------------- | | whoami | whoami | | id | ver | | ifconfig | ipconfig | | uname -a | tasklist | | ps -ef| netstat -an| | lsb_release -a | | ## 2. Broken Authentication Authentication is proving you are who you say you are. Authorization is proving you are allowed to do the actions you want to do. * To avoid password guessing attacks, ensure the application enforces a **strong password policy.** * To avoid brute force attacks, ensure that the application enforces an **automatic lockout after a certain number of attempts.** * **Implement Multi Factor Authentication** - If a user has multiple methods of authentication, for example, using username and passwords and receiving a code on their mobile device, then it would be difficult for an attacker to get access to both credentials to get access to their account. When developers forget to sanitize inputs, you can re-register a registered user and login as them. e.g if luffy is registered, then register as ' luffy' with a whitespace at the beginning then login and voila! ## 3. Sensitive Data Exposure When it comes to flat file databases, once you acquire the db you can inspect with sqlite3 which comes installed on kali Useful commands are: **sqlite3** tablename **.tables** : to find out which tables are on the db **PRAGMA table_info(table_name);** to give you the info on the table structure. **SELECT * FROM table_name;** to return the records in the table now that you understand the structure. As can be seen in the image below. ![](https://i.imgur.com/syroEsu.png) You can use [crackstation](https://crackstation.net/) for cracking easy hashes ## 4. XXE XML External Entity is a vulnerability that abuses features of XML Parsers / data. It can be used to * Allow attackers to interact with any back-end or external systems that the application itself has access to. * Cause Denial of Service. * Perform Server side request forgery (SSRF) inducing web apps to make requests to other applications. * Enable port scanning and in some cases lead to code execution. Types of XXE attacks: 1. in-band XXE attacks: attacker can receive an immediate response to the XXE payload. 2. out-of-band XXE attacks: alias blind XXE, there is no immediate response from the web app and the attacker must reflect the output of their XXE payload to another file or their own server. ### Understanding XML Extensible Markup Language (XML) is used to define a set of rules for encoding documents in a format that is both human-readable and machine-readable. **It's a markup language for storing and transporting data.** We use XML because: * It is both platform and programming language independent thus can be used on any system and supports change of systems if and when they occur * Data stored and transported using XML can be altered at any point in time without affecting its presentation. * XML allows validation using DTD(document type definition) and SCHEMA, ensuring the XML doc is free from syntax errors * XML data doesn't require any conversion when transferred between systems. ### DTD A doc type definition defines the structure and the legal elements and attributes of an XML file Usually an XML should start with an xml prolog as best practice as follows: - XML prolog ```xml=1 <?xml version="1.0" encoding="UTF-8"?> ``` This specifies the XML version and the encoding used in the XML document Note that every XML document **must contain a root element.** * To define a root element use !DOCTYPE * To define an element use !ELEMENT * To define an entity use !ENTITY ### Creating an XXE Payload - XXE Payload to read a file from system ```xml=1 <?xml version="1.0"?> <!DOCTYPE root [<!ENTITY read SYSTEM 'file:///etc/passwd'>]> <root>&read;</root> ``` Here we define an entity called read and setting its value to SYSTEM and the file path to read from. This payload should display the /etc/passwd file on vulnerable sites. ## 5. Broken Access Control **A Poison Null Byte is actually a NULL terminator**. By placing a NULL character in the string at a certain byte, the string will **tell the server to terminate at that point**, nulling the rest of the string. **An example of a poison nullbyte is %00** Note that to use this in a url , you would use **the url encoded version %2500** When Broken access control bugs are found they are categorized into two: 1. **Horizontal Privilege Escalation**: occurs when a user can perform actions or access data of another user with the same level of permissions. 2. **Vertical Privilege Escalation**: occurs when a user can perform actions or access data of another user with a higher level of permissions. ### Insecure Direct Object Reference (IDOR) Allows us to insecurely refer to an object e.g passing a different parameter to a url which allows us to view the related information while not authenticated as the user who is supposed to have access to that information. ## 6. Security Misconfiguration These include: * Poorly configured permissions on cloud services like S3 * Having unnecessary features enabled, like services, pages, accounts, privileges etc * Default accounts with unchanged passwords (sweet spot for IOT devices) * Error messages that are overly detailed and provide info useful for enumeration * Not using HTTP security headers, or revealing too much details in the server ## 7. XSS Cross-site Scripting is a type of injection attack that can allow an attacker to execute malicious scripts and have it execute on a victim's machine. A web app is vulnerable to XSS if it uses **unsanitized user input.** XSS is possible in Javascript, VBScript, Flash and CSS. 3 types of XSS: 1. **Stored XSS:** a.k.a Persistent XSS is javascript that is run when the server loads the page containing it. These can occur when the server does not sanitise the user data when it is uploaded to a page. These are commonly found on blog posts. 2. **Reflected XSS:** javascript that is run on the client-side end of the web application. These are most commonly found when the server doesn't sanitise search data. 3. **DOM-Based XSS:** DOM XSS (Document Object Model-based Cross-site Scripting) uses the HTML environment to execute malicious javascript. This type of attack commonly uses the <script></script> HTML tag. ``` tip: In Javascript window.location.hostname will show your hostname ``` ## 8. Insecure Deserialization Replacing data processed by an app with malicious code which enables an attacker to cause a DOS or RCE(Remote Code Execution) thus establishing a foothold in the organization. The malicious code leverages the serialization and deserialization process used by web apps. Owasp ranks this as 8/10 because it has **low exploitability** and its effectiveness is highly **dependent on the attackers skill level.** Serialization is the process of **converting objects used in programming into simpler, compatible formatting for transmitting between systems or networks** for further processing / storage. Deserialization is converting serialized information into their complex form i.e an object the application will understand. Insecure deserialization occurs when data from an untrusted party gets executed because there is no filtering or input validation; the system assumes that the data is trustworthy and will execute it no holds barred. ## 9. Components with known vulnerabilities This is prevalent since most organizations don't have a good patch culture. The threat model is basically: 1. find out which platform is being used 1. research on vulnerabilities of that platform 1. get a suitable exploit for the vulnerability 1. exploit ## 10. Insufficient Logging and Monitoring All actions done on a web app should be logged. Logs are useful during and after an incident and can help in: * tracing the attackers actions * thus minimizing the risk and impact * minimizing regulatory damange e.g wrt to privacy such as GDPR * minimizing the risk of further attacks while monitoring is useful before, during and after an incident and can help in preventing attacks to start with by alerting analysts to suspicious activities at the onset. Information that should be logged includes: * HTTP status codes * Time stamps * Usernames * API endpoints/page locations * IP addresses Common examples of suspicious activities include: * mutliple unauthorised attempts for a particular action * requests from anomalous ip addresses or locations * use of automated tools , leveraging on User-Agent headers or the speed of requests * common payloads: e.g xss payloads That's a wrap for this 101.