OWASP top 10

OWASP stands for Open Web Application Security Project, which is an open-source foundation for web app security. They have curated a list of top 10 vulnerabilities and the list is a good place to start with for making your apps more secure.

Here we will discuss the 2017 release candidate 2 of OWASP top 10 vulnerabilities.

1. Injection In programming, the commands and the data to be operated upon are defined by code.

For example, consider a signup form. Here we get the input(data) from the user and act up it using the commands we used to code the application. What if the input intended to be data acted as a command for the application. With that, the user can take the application to unindented states. This is an example of an injection attack. There are SQL injection, LDP injection, OS injection, XPath injection etc.
Access control is one way to prevent this type of attack.

Prevention:
- input validation: can include blacklisting and whitelisting of characters and their data types and lengths.
- prepared statements and stored procedures: the user must only be able to pass the parameters rather than a complete dynamic query. The developer can also have stored procedures(named queries) so that all required queries are kind of well defined.
- least privilege: ensure you only provide the required level of access.

1. Broken Authentication and session management Authentication is verifying who you are and what belongs to you. A session starts when an authenticated user starts using his account/resources. The most common was of authentication is a username and password. At times people might trick the user with some emails or phone calls which sound urgent in order to acquire their passwords and user names. This is called Social engineering/Pishing. With the increased computation power availability hackers can run periodic and systematic attacks to get access to an account and this is called Automated Attacks. One way is credential stuffing where the hacker periodically tries out the user credentials exposed in a security breach. As most of the people reuse the passwords this works so often. Another one is brute-foroce attack where the attacker will guess to the password and try different possible combinations of credentials. Broken application logic can also lead to broken auth. Suppose if you have a less efficient forgot password reset mechanism hackers can get hold of your accounts easily.

Solution:

• limit the number of retries
• stronger passwords
• encrypt the passwords well
• two-factor authentication where the user uses a password as well as an OTP to login.

1. Sensitive Data exposure
   At times the sensitive data might be leaked or exposed. It is always advised to encrypt data while storing and sending. Encryption(🔐) involves an algorithm(mathematical formula) and a key(🔑). If one has to decrypt the data they must know the algorithm and 🔑 used to encrypt it.
   Always try to store the least possible sensitive information which is only required.
   Prevention:

   • enforce PCI standards
   • enforce laws and regulations
   • reduce the scope. Always process, collect, store and transmit only the least required data.
   • encrypt sensitive data at rest and transit. TLS(successor of SSL), HTTPS(HTTP + TLS) and HSTS(HTTP Strict Transport Security). HSTS convert all HTTP connections to HTTPS.

2. XML External Entities(XXE)
   XXE is more like an injection attack that happens in a system where XML is used for inter-application communication.
   

XML is used to transfer data and files.
A malicious XML input from an external source is sent to an application with an intent to take down the entire application or Remote Code Execution(RCE).
Example of one such attack is XML Bomb, where an XML string get reproduced into 10x after each parsing finally results in DoS(Denial of Service)/Billions Laugh Attack attack. With this, the application is no more able to handle further requests due to memory overflow.

Prevention:
- disable XML external entities
- whitelist, blacklist and validating inputs
- upgrade the XML processor and libs

1. Broken access control
   Authorization is more related to enforcing user roles and allowing authenticated users to perform certain actions that their user role facilitates.
   Every application will have a certain kind of user roles, who are privileged to perform different levels of actions. Access control is broken if user roles are not being strictly enforced.
   
   Prevention:

   • enforce proper access control
   • logging and monitoring access control failures
   • manual testing of access control by security researchers(penetration testing), QA or developers in unit or integration tests

2. Security misconfiguration
   An application may consist of different infrastructure and software components. At times the misconfiguration of these components can end up making our applications vulnerable to attacks. Few examples are,

   • Error handling: during development, it is common to enable error handling. But once the application is being deployed in production we should ensure this error handling and logging being turned off so that the hackers can't know what exactly is failing and use it against us.
   • Default passwords and settings: many of the infra and software components are shipped with default passwords. We. should them to be removed and strong passwords are being used. Suppose if the hacker new which service we are using and is able to get access using the default password, then it will be troublesome.
   • Outdated libraries and frameworks The best approach is to provide least privilege to the services and they should have only the required privileges to access DB and other services. And in general no GOD users.

Prevention:

• harden all systems
• update and patch regularly
• test configurations

1. Cross-site scripting(XSS) Using <script/> to inject malicious scripts through an HTML input. They are mainly of the following types:
   • reflected cross-site scripting, which is more like pishing when the user clicks on a link that in turn executes a malicious code
   • stored XSS, happens when a user visits a page with a malicious payload. User doesn't have to do anything, he/she just need to visit the page. This kind of attack is more dangerous as it can spread too quickly and can end up being a worm.

XSS is used to

• steal credentials
• install keyloggers
• defame websites

Prevention:

• enable Content Security Policy(CSP
• applying Context-Sensitive Encoding. It ensures software doesn't interpret data as instructions as we tell it not to.
• use HTML entity encoding and URL encoding, which tells the software the inputs as data rather than code.
• escape unstructured HTTP data

1. Insecure deserialization Serialization is the process of converting digital information into a different format so that it can be stored well. Deserialisation is the reverse process of converting the store information into digital format. There are chances for hackers to tamper the serialized information and cause chaos after deserialisation and this is referred to as insecure deserialisation. Most of the time developers use libraries for serialising and deserialising data. But most of these libs are not foolproof and may miss many guards.

Prevention:

• use encryption and have in place integrity checks
• logging and error reporting to detect insecure deserialisation
• isolate code that deserialises

1. Using components with unknown vulnerabilities The software has bugs. In modern-day development, we make use of a lot of open-source libraries, frameworks and systems. But if those components have any vulnerabilities we are also getting vulnerable by using it. There is a list maintained by (CVE)[https://cve.mitre.org/index.html]. If an attacker knows a bug in a component it can be his/her doors to our system too.

Prevention:

• continuously monitor the components and dependencies for security flaws
• if the patches are time taking, apply virtual patch using Web Application Firewall(WAF).

1. Insufficient logging and monitoring Logging is noting down what is having in a system continuously. Logging is kind of an electronic record of things happening. This can include login, logouts, error, input validation failures, etc. We not always should just log it but monitor them closely too, to understand what is actually happening. To make it effective there must be an incident reporting system in place too. The time to detect a breach is nearly 197 days.

Preventions:

• ensure you log what is required and no sensitive information. But it can have sufficient user context so that we can know who is doing what.
• the logs must be well monitored so that we can spring to act quickly.
• have an Incident Response Plan, which says how to respond to an incident. This lay down the steps to be carried out and who will do what.