The Open Web Application Security Project (OWASP) is an international organization dedicated to enhancing the security of web applications.
The conference held at Mantra Labs by one of our experienced test engineer Rijin. Here he has discussed the current top 10 web application security risks worldwide. The list describes each vulnerability, provides examples, and offers suggestions on how to avoid it.
The top 10 web application security risks worldwide are:
- Broken authentication and session management
- Cross-site scripting
- Indirect object security reference
- Security misconfiguration
- Sensitive data exposure
- Missing function level access control
- Cross site forgery
- Using components with known vulnerabilities: Heartbleed and Shellshock
- Unvalidated redirects and forwards
Link to Hackerone Bug reports:
From here you can take the understanding and would get an idea of ongoing security issues/bugs. How the hackers are exploiting the web applications. Various security/penetration bugs are listed here.
This is when an attacker sends rogue content to a web application interpreter causing the interpreter to execute authorized commands. The most common of the code injection attacks are SQL Injections, also known as SQLi. An SQLi attack is done when malformed code is sent to the database server, thus leading to the exposure of your data. And this attack style is so simple and easy, anyone with access to the internet can do it – SQLi scripts are available for download and can be acquired easily.
How is it done?
The character “‘” is entered into the search field and pressing the button leads to an error page which displays more information than needed.
This example showcases a badly and insecurely programmed application that is incapable of handling SQL Injections. Just a few illegal characters with a little sniffing around leads the hacker to this string: “‘ union select password from users;”. He can then implement this finding to harvest usernames and passwords from the database. This is just one basic way to exploit application databases.
Tool commonly used for SQL Injection
sqlmap is an open source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over of database servers.
It is commonly used in Kali-linux.
After finding a vulnerable page you can find database by typing :
sqlmap –u (url) –dbs
Guide to exploit via sqlmap
For practice you can use the following websites:
You can also find SQL vulnerable website on your own. You just have to look for
- php?id=(any Number)
- login.php?id=(any number)
- index.php?id=(any number)
Examples of SQL injection:
2.BROKEN AUTHENTICATION AND SESSION MANAGEMENT
Incorrect implementation of authentication schemes and session management can allow unauthorized users to assume the identities of valid users.
Broken Authentication and Session Management attacks are anonymous attacks with the intention to try and retrieve passwords, user account information, IDs and other details.
Key Points to check if you are vulnerable:
- User authentication credentials aren’t protected when stored using hashing or encryption.
- Credentials can be guessed or overwritten through weak account management functions (e.g., account creation, change password, recover password, weak session IDs).
- Session IDs are exposed in the URL (e.g., URL rewriting).
- Session IDs are vulnerable to session fixation attacks.
- Session IDs don’t timeout, or user sessions or authentication tokens, particularly single sign-on (SSO) tokens, aren’t properly invalidated during logout.
- Session IDs aren’t rotated after successful login.
- Passwords, session IDs, and other credentials are sent over unencrypted connections.
Examples of attack scenarios:
Airline reservations application supports URL rewriting, putting session IDs in the URL:
An authenticated user of the site wants to let his friends know about the sale. He e-mails the above link without knowing he is also giving away his session ID. When his friends use the link they will use his session and credit card.
Application’s timeouts aren’t set properly. User uses a public computer to access site. Instead of selecting “logout” the user simply closes the browser tab and walks away. Attacker uses the same browser an hour later, and that browser is still authenticated.
Insider or external attacker gains access to the system’s password database. User passwords are not properly hashed, exposing every user’s’ password to the attacker.
Vulnerability to ‘Sensitive Data exposure’:
- Is any of this data stored in clear text long term, including backups of this data?
- Is any of this data transmitted in clear text, internally or externally? Internet traffic is especially dangerous.
- Are any old / weak cryptographic algorithms used?
- Are weak crypto keys generated, or is proper key management or rotation missing?
- Are any browser security directives or headers missing when sensitive data is provided by / sent to the browser? (Nikto)
Prevention from Sensitive data exposure:
- Make sure you encrypt all sensitive data .
- Don’t store sensitive data unnecessarily. Discard it as soon as possible. Data you don’t have can’t be stolen.
- Ensure strong standard algorithms and strong keys are used, and proper key management is in place.
- Ensure passwords are stored with an algorithm specifically designed for password protection, such as bcrypt, PBKDF2, or scrypt.
- Disable autocomplete on forms collecting sensitive data and disable caching for pages that contain sensitive data.
Protection against broken authentication and session management:
-Minimum size and complexity.
-Complexity depends on the usage of combinations of alphabetic, numeric, and/or non- alphanumeric characters
-Change password periodically
-Prevent from reusing previous passwords.
-Restrict to a defined number of login attempts per unit of time and repeated failed login attempts should be logged.
-System should not indicate whether it was the username or password that was wrong if a login attempt fails.
Password Change Controls
-Users should always be required to provide both their old and new password when changing their password .
-If forgotten passwords are emailed to users, the system should require the user to reauthenticate whenever the user is changing their e-mail address, otherwise an attacker who temporarily has access to their session (e.g., by walking up to their computer while they are logged in) can simply change their e-mail address and request a ‘forgotten’ password be mailed to them.
-Passwords must be stored in either hashed or encrypted form
-Encryption should be used when the plain text password is needed
Session ID Protection
-A user’s entire session should be protected via SSL.
-Session ID should never be included in the URL as they can be cached by the browser.
-Session IDs should be long, complicated, random numbers that cannot be easily guessed.
-Session IDs can also be changed frequently during a session to reduce how long a session ID is valid. Session IDs must be changed when switching to SSL, authenticating, or other major transitions.
-Authentication and session data should never be submitted as part of a GET, POST should always be used instead.
-Authentication pages should be marked with all varieties of the no cache tag to prevent someone from using the back button in a user’s browser to backup to the login page and resubmit the previously typed in credentials.
Examples of broken authentication and session management:
3.CROSS SITE SCRIPTING
This is when a browser unknowingly executes scripts to hijack sessions or redirect to a rogue site.
Cross-site Scripting (XSS) refers to client-side code injection attack wherein an attacker can execute malicious scripts (also commonly referred to as a malicious payload) into a legitimate website or web application. XSS is amongst the most rampant of web application vulnerabilities and occurs when a web application makes use of unvalidated or unencoded user input within the output it generates.
By leveraging XSS, an attacker does not target a victim directly. Instead, an attacker would exploit a vulnerability within a website or web application that the victim would visit, essentially using the vulnerable website as a vehicle to deliver a malicious script to the victim’s browser.
There are basically two types of XSS:
- A Stored Cross Site Scripting vulnerability occurs when the malicious user can store some attack which will be called at a later time upon some other unknowing user. The attack is actually stored in some method to be later executed.
- The storage of a method could involve a database, or a wiki, or blog. Basically the malicious user has stored some type of attack, that when an unknowing user will encounter this, the attack will be executed. The stored method actually not only has the problem of incorrect checking for input validation, but also for output validation. Even if data has been sanitized upon input, it should also be checked for in the output process. By checking and validated the output, you could also uncover unknown issues during the input validation process.
- The malicious user has discovered that a field within a website or web application holds a XSS vulnerability. This malicious user then crafts a way to use the vulnerability to execute something malicious to some unknown user. Reflected XSS vulnerabilities occur when a unknowing user is directed to a web application that has a XSS vulnerability, by the malicious user. Once the unknowing user gets to the web site or application the malicious user’s attack is executed.
- The attack is crafted by a series of url parameters that are sent via a url. The malicious user then sends his/her malicious url with the url parameters to unknowing users. This is typically sent by email, instant messages, blogs or forums, or any other possible methods.
How to test for XSS injection vulnerabilities, example:
You can determine if a web-based application is vulnerable to XSS attacks very easily. A simple easy test is to take a current parameter that is sent in the HTTP GET request and modify it. Take for example the following request in the browser address URL bar. This url will take a name parameter that you enter in a textbox and print something on the page. Like “Hello George, thank you for coming to my site” http://www.yoursite.com/index.html?name=george And modify it so that add an extra some additional information to the parameter. For example try entering something similar to the following request in the browser address URL bar.
http://www.yoursite.com/index.html?name=<script>alert(‘You just found a XSS vulnerability’)</script>
If this pops up an alert message box stating “You just found a XSS vulnerability”, then you know this parameter is vulnerable to XSS attacks. The parameter name is not being validating, it is allowing anything to be processed as a name, including a malicious script that is injected into the parameter passed in. Basically what is occurring is normally where the name George would be entered on the page the </script></script> message is instead being written to the dynamic page.
The alert message just is an example of how to test for the XSS vulnerability.
Some examples of cross-site scripting attack vectors:
Tools that can be used:
Zaproxy: It’s a freeware.
Also Burp Suite and Beef can be used to find out XSS vulnerability.
4.INDIRECT OBJECT SECURITY REFERENCE
An attacker can access a reference to a file or directory and manipulate that reference to gain unauthorized access to other objects.
A direct object reference occurs when a developer exposes a reference to an internal implementation object, such as a file, directory, database record, or key, as a URL or form parameter. An attacker can manipulate direct object references to access other objects without authorization, unless an access control check is in place.
- Vulnerability to Insecure Direct Object References
- For direct references to restricted resources, does the application fail to verify the user is authorized to access the exact resource they have requested?
- If the reference is an indirect reference, does the mapping to the direct reference fail to limit the values to those authorized for the current user?
- To test Insecure Direct Object References
To test for this vulnerability the tester first needs to map out all locations in the application where user input is used to reference objects directly. For example, locations where user input is used to access a database row, a file, application pages and more. Next the tester should modify the value of the parameter used to reference objects and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization.
The best way to test for direct object references would be by having at least two (often more) users to cover different owned objects and functions. For example two users each having access to different objects (such as purchase information, private messages, etc.), and (if relevant) users with different privileges (for example administrator users) to see whether there are direct references to application functionality. By having multiple users the tester saves valuable testing time in guessing different object names as he can attempt to access objects that belong to the other user.
Some basic examples:
The value of a parameter is used directly to retrieve a database record
- In this case, the value of the invoice parameter is used as an index in an invoices table in the database. The application takes the value of this parameter and uses it in a query to the database. The application then returns the invoice information to the user.
- Since the value of invoice goes directly into the query, by modifying the value of the parameter it is possible to retrieve any invoice object, regardless of the user to whom the invoice belongs. To test for this case the tester should obtain the identifier of an invoice belonging to a different test user (ensuring he is not supposed to view this information per application business logic), and then check whether it is possible to access objects without authorization.
Examples of the attack:
Testing traversal/file include
Many web applications use and manage files as part of their daily operation. Using input validation methods that have not been well designed or deployed, an aggressor could exploit the system in order to read or write files that are not intended to be accessible.
Testing techniques to test this flaw
In order to determine which part of the application is vulnerable to input validation bypassing, the tester needs to enumerate all parts of the application that accept content from the user. Here are some examples of the checks to be performed at this stage:
Are there request parameters which could be used for file-related operations?
Are there unusual file extensions?
Are there interesting variable names?
An attacker could insert the malicious string “../../../../etc/passwd” to include the password hash file of a Linux/UNIX system. This kind of attack is possible only if the validation checkpoint fails; according to the file system privileges, the web application itself must be able to read the file.
It also possible to include files and scripts located on external website.
If protocols are accepted as arguments, as in the above example, it’s also possible to probe the local filesystem this way.
If protocols are accepted as arguments, as in the above examples, it’s also possible to probe the local services and nearby services.
http://example.com/index.php?file=http://localhost:8080 or http://example.com/index.php?file=http://192.168.0.2:9080
Example of path traversal: https://hackerone.com/reports/150018
Improper server or web application configuration leading to various flaws.
- Debugging enabled
- Incorrect folder permissions
- Using default accounts or passwords
Vulnerability to Security Misconfiguration
Is your application missing the proper security hardening across any part of the application stack? Including:
- Is any of your software out of date? This software includes the OS, Web/App Server, DBMS, applications, APIs, and all components and libraries.
- Are any unnecessary features enabled or installed (e.g., ports, services, pages, accounts, privileges)?
- Are default accounts and their passwords still enabled and unchanged?
- Does your error handling reveal stack traces or other overly informative error messages to users?
- Are the security settings in your application servers, application frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values?
Scenario #1: The app server admin console is automatically installed and not removed. Default accounts aren’t changed. Attacker discovers the standard admin pages are on your server, logs in with default passwords, and takes over.
Scenario #2: Directory listing is not disabled on your web server. An attacker discovers they can simply list directories to find any file. The attacker finds and downloads all your compiled Java classes, which they decompile and reverse engineer to get all your custom code. Attacker then finds a serious access control flaw in your application.
Scenario #3: App server configuration allows stack traces to be returned to users, potentially exposing underlying flaws such as framework versions that are known to be vulnerable.
Scenario #4: App server comes with sample applications that are not removed from your production server. These sample applications have well known security flaws attackers can use to compromise your server.
Protection against Security misconfigurations:
- Install latest updates and security patches. Have an easy to manage updating process with test environments to check updates before deploying to production environments.
- Remove sample applications that ship with content delivery systems and web frameworks. Most tools that help build web applications include demo and sample code to help teach developers how to use the tools and get you started. These samples and demos should be removed. They provide a known target for anyone attempting to compromise web application security.
- Remove unused features, plugins and web pages. Only include the parts of web applications that you need to provide your service to end users. Remove any plugins or functionality that you are not using.
- Turn off access to setup and configuration pages. Don’t leave the setup and configuration pages available for users to use.
- Change usernames, passwords and ports for default accounts. Web application frameworks and libraries often ship with default administration names, passwords and access ports enabled. Everyone knows these. Change all these to non standard usernames, passwords and ports.
- Don’t share passwords between accounts on Dev, Test and Production systems. Related to the point above. Don’t use the same administration accounts and settings across your Dev, Test and Production systems.
- Turn off debugging so that internal info isn’t sent back in response to test queries or errors. Excessive debugging information can be used to glean information about a web applications configuration.
Good read :
Stay tuned for rest of the security risks, they are coming shortly.