Open Web Application Security Project – Top Ten Security Risks

Everyone is looking for harmony and happiness. One may have the money, a beautiful family, and lots of properties, but does that make one’s life happy and harmonious? The safety, security and the protection of all these should be taken proper care of too. Money is nothing without a strong bank or a locker. Similarly, you need a secure place for your family and a proper fence for your property. So, security is a top concern and should be given the highest priority in our day-to-day life.

But how do we do that?

Normally, we put our money in a locker, lock it, maybe put on the toughest combination of password known, and try the strength of the lock. If it is strong then, your money is safe, right? Nope. Thieves nowadays are very clever. They may use your own locker key, try on some software to crack the password, or they may even knock you out and use you unknowingly to open it for them! The methods are innumerous!

Now, let us discuss the issue of security in the case of web application. Normally, we secure all the applications from unauthorized access using password protection, encrypted dll, attached dongles etc. After all of this, we think (yes, most of us) that no one can break this! My files are super-protected! But, please remember that nothing is unbreakable online. The best we can do to protect our files is making the breaking-in process harder.

How do we secure our application data? For that we need to know how these files get stolen. What are the top vulnerabilities of a web application? It is here the name OWASP (Open Web Application Security Project) comes into play. OWASP is a none profit organization dedicated to enabling organizations to conceive, develop, acquire, operate, and maintain applications that can be trusted. This organization identifies and fights back against the big threads in terms of software security. Let us now check what the Top Ten powerful awareness documents for web application security as noted by OWASP are.

1    Injection

The most often seen types of Injections are Command , SQL, Code, Xpath , RegExand XXE (XML External Entities) Injections.

SQL-injection attacks can be achieved in applications that uses user input in order to construct SQL statements. If the data provided by the user is not in some way checked and cleaned an attacker can write its own SQL statements when submitting data to the application and because of this perform different actions with the applications database.

Command injection is a method of executing OS system commands in general. These commands are delivered with user-controlled input data and then incorrectly described (or not described at all). This vulnerability is very common for web based control panels and many kinds of web wrappers to some os-native scripts.

In code injections, hackers try to make your application include their external file with malicious code and run it.

If an application uses run-time XPath query construction, inserting unsafe user input into the query, it may be possible for the attacker to inject data into the query such that the newly formed query will be parsed in a way differing from the programmer’s intention.

Regular Expression Injection uses the substitution modifier for regular expressions to inject code in a web application

An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser

2    Broken Authentication and Session Management (XSS)

Following actions triggers 2^nd bigger security thread as per OWASP

1. Storing user credentials without hashing or encrypting them.
2. Easily guessed passwords.
3. Poorly secured password change features.
4. Poorly secured password recovery features.
5. Session IDs exposed in a URL.
6. Session IDs are vulnerable to session fixation attacks.
7. Session IDs don’t reasonably timeout or sessions aren’t properly invalidated during logout.
8. Session IDs aren’t rotated after a successful login.
9. Passwords, session IDs, and other credentials are sent over unencrypted connections.
10. Browser caching is enabled.

3    Cross Site Scripting (XSS)

Cross-site scripting is a vulnerability that allows attackers to inject malicious code into webpages viewed by other users, using credentials that the application trusts.

• a malicious attacker can inject a (client-side) script into a web page that is also viewed by other users ( example : comment section in a blog)
• when another user views the page, he/she also downloads and executes the malicious script
• XSS exploits the trust that the victim has in the (owner of the) visited web site; unfortunately, if the site is vulnerable to XSS, then this trust should not be transferred to the site’s content

4    Insecure Direct Object References

Insecure Direct Object References occur when an application provides directaccess to objects based on user-supplied input. As a result of this vulnerability attackers can bypass authorization and access resources in the system directly

5    Security Misconfiguration

1. Unencrypted transition of sensitive data
2. Insufficient Session ID length
3. Missing Custom Error Page
4. Creating Debug Binary (asp.net)
5. Password in config file (asp.net)
6. Not using Input Validation Framework(asp.net)

6    Sensitive Data Exposure

Many web applications do not properly protect sensitive data, such as credit cards, tax ids, and authentication credentials.

Attackers may snip or alter such inadequately protected data to conduct identify theft, credit card fraud, or other crimes.

7    Missing Function Level Access Control

Virtually all web applications verify function level access rights before making that functionality visible in the UI. However, applications need to perform the same access control checks on the server when each function is accessed. If requests are not verified, attackers will be able to forge requests in order to access unauthorized functionality.

8    ross Site Request Forgery (CSRF)

misleading the user to do an un intended task.

If a user logs into Internet banking to view his deposits and he did not quit the internet banking system, and instead he visits other websites and also the bank’s forum, if the attacker carefully constructs a malicious link and lures the user to click on the link, then the user’s bank account funds may be transferred to the attacker’s specified account.

9    sing Components with Known Vulnerabilities

Bugs in modules and components of the web application

This kind of threat occurs when the Components such as libraries, frameworks used within the app almost always executes with full privileges. If a vulnerable component is exploited it makes hackers job easier to cause a serious data loss or server takeover.

10    Un validated Redirects and Forwards

Redirects allow web applications to direct users to different pages within the same application or to external sites. Applications utilize redirects to aid in site navigation and, in some cases, to track how users exit the site. Open redirect vulnerabilities occur when a web application redirects clients to any arbitrary URL that can be controlled by an attacker.

Here we discussed the main loop holes for a hacker to access our files. I know that most of our developers are taking care of these vulnerabilities. Still, better be safe than sorry. So make sure, that we never give a chance to an outsider to get access to our data. Always update yourself regarding the OWSAP list because the sneaky attackers are always looking for new loopholes.