Top web application vulnerabilities can be prevented by testing

Tram Ho

When talking about cyber risk, the first thing we can think of is malware. However, many network attacks are related to applications. Security holes are always a headache for website administrators. These vulnerabilities allow hackers to exploit – attack – infiltrate – breach data of corporate website.

Here are the top most common web security vulnerabilities under OWASP standards:

1. Injection vulnerability (Malicious code insertion error)

Injection is a vulnerability that occurs due to a lack of reliable input filtering. When you pass unfiltered data to the database (eg SQL injection vulnerability), to the browser (XSS vulnerability), to the LDAP server (LDAP Injection vulnerability) or to any other location. The problem is that an attacker can insert malicious code to cause data breaches and take control of the client’s browser.

Any information your application receives must be filtered by Whitelist. Because if you use the Blacklist the information filtering will be very easy to bypass (Bypass). Pattern matching will not work if Blacklist is set up.

  • How to prevent vulnerabilities:

Countering this vulnerability is simply a matter of whether you properly filtered the input or whether you consider whether an input can be trusted or not. Basically, all inputs have to be filtered and checked unless the input is certainly reliable. (However, it is always necessary to carefully check all the inputs).

For example, in a system with 1000 inputs, successfully filtering 999 inputs is not enough as this still leaves a part like an “Asin heel”, which can damage your system at any time. You might think that it is a good idea to include SQL query results in another query because the database is trustworthy. Unfortunately, input can come indirectly from people with bad intentions.

Filtering data is quite difficult so we should use the filtering functions available in our framework. These proven features will do a thorough check. We should consider using frameworks as this is one of the most effective ways to protect your server.

2. Broken Authentication

This is a group of problems that can occur during validation. It is advisable not to develop encryption solutions on your own as it is difficult to do exactly it.

There are many risks that can be encountered during validation:

  • The URL may contain Session ID and leak it in the Referer Header of another user.
  • Passwords are not encrypted or easy to decrypt while storing.
  • Session Fixation vulnerability.
  • Session Hijacking attacks can occur when the session expiration time is not properly deployed or when HTTP (no SSL secure) is used …
  • How to prevent vulnerabilities:

The simplest way to avoid this web security vulnerability is to use a framework. In case you want to create your own authenticator or encryption, think about the risks you will face and consider it for yourself.

3. XSS (Cross Site Scripting) vulnerability

Cross-scite Scripting (XSS) vulnerability is a very common vulnerability. The attacker inserts JavaScript scripts into the web application. When this input is not filtered, it is executed by malicious code on the user’s browser. An attacker can obtain the user’s cookies on the system or trick the user into malicious websites

  • How to prevent vulnerabilities:

One simple way of web security is to not return the HTML tag to the user. This also protects against HTML Injection – a similar attack in which a hacker attacks HTML content – has no serious impact but is quite troublesome for users. Usually the solution is simply Encode (convert to another data format) all the HTML tags.

For example the <script> tag is returned as <script & gt>

4. Security Misconfiguration

In fact, the web server and most applications are misconfigured. Perhaps due to a few errors such as:

  • Run the application when debug mode is enabled.
  • Directory listing
  • Using outdated software (WordPress plugin, old PhpMyAdmin)
  • Installation of unnecessary services.
  • Do not change the default key or password
  • Returns an error processing information for the attacker to exploit, such as stack traces.
  • How to prevent vulnerabilities:

Have a good (preferably automated) “build and deploy” process. An audit of the security precision on the server is needed before you deploy it.

5. Sensitive data exposure

This vulnerability belongs to the crypto and resource aspect. Sensitive data must be encrypted at all times, including when it is sent and when stored – no exceptions are allowed. Credit card information and user passwords are never sent or stored unencrypted. Obviously encryption and hashing algorithms are not a weak way of security. In addition, web security standards suggest using AES (256 bit or more) and RSA (2048 bit and above).

It should be said that Session IDs and sensitive data should not be passed in sensitive URLs and cookies so there is a security flag.

  • How to prevent vulnerabilities:
  • Use HTTPS with proper certificate and PFS (Perfect Forward Secrecy). Do not receive anything on non-HTTPS connections. There is a safety flag on the cookie.
  • There is a need to limit sensitive data that can be exposed. If you don’t need this sensitive data, destroy it. Data cannot be stolen.
  • Never store credit card information, otherwise have to deal with PCI compliance. Sign up for a payment processor like Stripe or Braintree.
  • If there is sensitive data that really needs it, encrypt it store and make sure all passwords are used by the Hash function for protection. For Hash, bcrypt should be used. If you are not using bcrypt encryption, learn about the Salt code to prevent rainbow table attacks.

Do not store encryption keys in addition to protected data. This is like a car lock with the key always there. Protect your backups with encryption and make sure your keys are private.

6. Missing function level access control (authorization error)

This is just a mistake in the issue of decentralization. It means that when a function is called on the server, the authorization is not correct. Developers rely on the fact that the server side creates the user interface and they think that the functionality is not accessible by the client if not provided by the server.

However, an attacker can always request “hidden” functions and will not be hindered by the user interface not allowing these functions. Imagine in the user interface there is only the / admin panel and the button if the user is really an admin. There’s nothing to stop an attacker from discovering these features and misusing it without authorization.

  • How to prevent vulnerabilities:

On the server side, thoroughly decentralized from design must always be done. There are no exceptions – every vulnerability leads to all sorts of serious problems


Share the news now

Source : Viblo