We will be talking about three degrees of security vulnerabilities that affect enterprise and consumer-oriented web applications: high-severity, medium-severity, and low-severity.
I. High-Severity Vulnerabilities
High-severity vulnerabilities are security flaws that enable hackers to take complete control over a targeted application without having direct access to it.
Cross-Site Scripting (XSS)
SQL Injection
Server-side JavaScript Injection (SSJI)
Remote Code Execution
File Inclusion and Directory Traversal
II. Medium-Severity Vulnerabilities
Medium-severity flaws can partially compromise the confidentiality, integrity, and availability (CIA) of a website or web application. These flaws enable hackers to access business data and modify it to prevent your employees and customers from using it when needed.
Cross-Site Request Forgery
Denial of Service (DoS)
Security misconfiguration (Directory Listing)
Transport Layer Security (TLS)/Secure Socket Layer (SSL)
III. Low-Severity Vulnerabilities
Unlike high-severity and medium-severity vulnerabilities, low-severity flaws cannot be exploited over a network and require authorised access or direct user involvement to take control over a web app.
Insufficient protection.
Failure to encrypt sensitive data.
Using components with known vulnerabilities
Details of above Vulnerabilities:
Let’s cover all of them one by one.
1. Cross-Site Scripting (XSS)
Cross-Site Scripting is a commonly used technique that allows running external JavaScript in the context of the attacked website. XSS allows getting access to full Web API. The simplest example of XSS attack implies that a hacker finds a vulnerable input field on the page and creates a link that injects a snipper to another page. After the link is opened by a user, it’s up to the hacker what will be happened next.
XSS is a high-rated security vulnerability since the attacker can get access to LocalStorage, SessionStorage, or cookies. That’s why it’s recommended not to store any sensitive data in these storages.
2. SQL Injection
SQL injection vulnerabilities exist for websites and apps powered by SQL database software( Structured Query Language). SQL software stores and organizes business data like customer records and payment info.
As SQL databases require authentication, so SQL injection is implemented through app level.
Thus, hackers who skip the authentication scheme of a web application to retrieve contents of an entire database. SQL injections accounted for 64% of web app attacks that were registered through 2016.
Injection flaws result from a classic failure to filter untrusted input. It can happen when you pass unfiltered data to the SQL server (SQL injection), to the browser (XSS), to the LDAP server (LDAP injection), or anywhere else. The problem here is that the attacker can inject commands to these entities, resulting in loss of data.
3. Server-side JavaScript Injection (SSJI)
Server-side JavaScript Injection is one of the most widespread web app vulnerabilities on the web nowadays. It’s a pretty common thing when a developer accidentally introduces proneness into his web application by simple misconfiguration. For example, the **eval **function can be pretty open for attacks and can be exploited with ease.
You should avoid the use of the eval function to decrease the risk of such vulnerabilities. It’s used mostly for speed benefits, but it can compile and execute any JavaScript code which significantly increases the risks.
If you use the concatenation of string of unsanctioned dynamic user input, be prepared to meet some unpleasant consequences.
4. Remote Code Execution
Remote code execution allows hackers to trigger code execution over the internet.
These attacks typically originate from one of your employees who clicks on an email link to a 3rd-party website. That website exploits the vulnerabilities of a web browser or the operating system (OS) running on your corporate computers and infects them with malware.
A hacker can then manipulate the malicious program over the Internet to access sensitive data or lock the computers and demand ransom. Ransomware attacks, for example, grew by 250% last year(link is external) and caused over $5 billion in damage.
5. File Inclusion and Directory Traversal
These vulnerabilities allow intruders to read directories and files outside the root directory, the top directory of a web app file system. During a file inclusion attack, access to any data stored “above” the root directory, for example, other websites’ directories, are inaccessible to users but are accessible to hackers.
Eg. http://192.168.80.134/dvwa/vulnerabilities/fi/?page=../../../../../../etc/passwd
The “../” characters used in the example above represent a directory traversal. The number of “../” sequences depends on the configuration and location of the target web server on the victim machine. Some experimentation may be required.
We can see that the contents of /etc/passwd are displayed on the screen. A lot of useful information about the host can be obtained this way.
6. Cross-Site Request Forgery
CSRF is an attack that exploits the mechanism of sending HTTP requests from the browser. If a user’s PC stores some cookies from a particular website, these cookies will be sent with the request, and it doesn’t matter who starts a given request. Thus, if you let things slide and don’t defend your web app against CSRF, a hacker can steal the accounts of your users.
In the case of CSRF, a 3rd party site issues requests to the target site (e.g., your bank) using your browser with your cookies / session. If you are logged in on one tab on your bank’s homepage, for example, and they are vulnerable to this attack, another tab can make your browser misuse its credentials on the attacker’s behalf, resulting in the confused deputy problem. The deputy is the browser that misuses its authority (session cookies) to do something the attacker instructs it to do.
Consider this example:
Attacker Bot wants to lighten target ram’s PayTm wallet by transfering some of his money to her. PayTm bank is vulnerable to CSRF. To send money, Ram has to access the following URL:
http://example.com/app/transferFunds?amount=150000&destinationAccountNumber=4673243243
After this URL is opened, a success page is presented to Ram, and the transfer is done. Bot also knows, that Ram frequently visits a site under her control at https://medium.com/@engineerchirag, where she places the following snippet:
Upon visiting Bot’s website, Ram’s browser thinks that Bot links to an image, and automatically issues an HTTP GET request to fetch the “picture”, but this actually instructs Ram’s bank to transfer $150000 to Alice.
Incidentally, in addition to demonstrating the CSRF vulnerability, this example also demonstrates altering the server state with an idempotent HTTP GET request which is itself a serious vulnerability. HTTP GET requests must be idempotent (safe), meaning that they cannot alter the resource which is accessed. Never, ever, ever use idempotent methods to change the server state.
7. Denial of Service (DoS)
A distributed denial-of-service (DDoS) attack is a malicious attempt to disrupt normal traffic of a targeted server, service or network by overwhelming the target or its surrounding infrastructure with a flood of Internet traffic.
DDoS attacks are popular because of their simplicity. During a DDoS attack, hackers basically generate a very large number of requests to a server in order to overwhelm it. The main purpose of these kind of attacks is to prevent legitimate users from accessing the server. The attack can be initiated through any individual system or group of systems or crawlers and can use any mechanism to flood servers with huge amount of information and choke it.
8. Security misconfiguration (Directory Listing)
In my experience, web servers and applications that have been misconfigured are way more common than those that have been configured properly. Perhaps this because there is no shortage of ways to screw up. Some examples:
Running the application with debug enabled in production.
Having directory listing enabled on the server, which leaks valuable information.
Running outdated software (think WordPress plugins, old PhpMyAdmin).
Having unnecessary services running on the machine.
Not changing default keys and passwords. (Happens way more frequently than you’d believe!)
Revealing error handling information to the attackers, such as stack traces.
9. Transport Layer Security (TLS)/Secure Socket Layer (SSL)
The SSL and TLS protocols enable two parties to identify and authenticate each other and communicate with confidentiality and data integrity.
Vulnerabilities that allow intruders to access data transferred between client and server.
10. Failure to encrypt sensitive data.
This web security vulnerability is about crypto and resource protection. Sensitive data should be encrypted at all times, including in transit and at rest. No exceptions. Credit card information and user passwords should never travel or be stored unencrypted, and passwords should always be hashed. Obviously the crypto/hashing algorithm must not be a weak one — when in doubt, web security standards recommend AES (256 bits and up) and RSA (2048 bits and up).
And while it goes without saying that session IDs and sensitive data should not be traveling in the URLs and sensitive cookies should have the secure flag on, this is very important and cannot be over-emphasized.
11. Insufficient protection
This is simply an authorization failure. It means that when a function is called on the server, proper authorization was not performed. A lot of times, developers rely on the fact that the server side generated the UI and they think that the functionality that is not supplied by the server cannot be accessed by the client. It is not as simple as that, as an attacker can always forge requests to the “hidden” functionality and will not be deterred by the fact that the UI doesn’t make this functionality easily accessible. Imagine there’s an /admin panel, and the button is only present in the UI if the user is actually an admin. Nothing keeps an attacker from discovering this functionality and misusing it if authorization is missing.
12: Using components with known vulnerabilities
The title says it all. I’d again classify this as more of a maintenance/deployment issue. Before incorporating new code, do some research, possibly some auditing. Using code that you got from a random person on GitHub or some forum might be very convenient, but is not without risk of serious web security vulnerability.
I have seen many instances, for example, where sites got owned (i.e., where an outsider gains administrative access to a system), not because the programmers were stupid, but because a 3rd party software remained unpatched for years in production. This is happening all the time with WordPress plugins for example. If you think they will not find your hidden phpmyadmin installation, let me introduce you to dirbuster.
The lesson here is that software development does not end when the application is deployed. There has to be documentation, tests, and plans on how to maintain and keep it updated, especially if it contains 3rd party or open source components.
Prevention over above Vulnerabilities:
Hold on, let’s wait for my next article. Stay tuned @engineerchirag.
Wrapping up
Woo! That’s all about most popular security concern related to web apps. In my next article we will discuss all about it’s prevention and cool techniques.
Was this article helpful for you? Let me know in the comments below if you have any questions or thoughts! I’d love to hear them :)
Thanks for reading. Did this article help you in any way? If I did, I hope you consider sharing it you might just help someone who felt the same way you did before reading the article. Thank you.
Sharing makes you bigger than you are. The more you pour out, the more life will be able to pour in.
Top comments (0)