Mitigation Strategies – Web Application Security

Mitigation Strategies for Web Application

Written by Darshit Varotaria

I'm a Web Application Pentester, Security Researcher and Bug Hunter.

September 2, 2020

Hello Techies! In this blog, I’m sharing mitigation strategies points which you should be knowing when you are going for a cyber-security Analyst/Consultant interview. I have noted down these point from portswigger. Below is the list of vulnerabilities:

01.Web Cache Poisoning Mitigation Strategies:

  1. Disable caching if not required.
  2. Restrict caching to static responses and make sure the version details can’t be tricked by the attacker from the back-end.
  3. If you are using third-party technology then make sure you understand its security implications.
  4. Check the headers supported by CDN (Content Delivery Network).
  5. Continuously track client-side vulnerabilities and apply the patch.

02.Information Disclosure Mitigation Strategies:

  1.  Make sure the internal team understands which info is considered to be sensitive.
  2. Avoid adding sensitive comments in the Static Code. If it’s necessary then make sure you remove it after the task gets completed.
  3. Use generic error codes as attackers can get clues from the behaviour pattern of the application.
  4. Remove sensitive information from Github like testing code, API keys, default credentials etc.
  5. Understand third-party security implications and disable features which are not required.

03.Insecure Deserialization Mitigation Strategies:

  1. Deserialization of user input should be avoided.
  2. The digital signature should be used to check the integrity of data at the beginning of the deserialization process.
  3. Class-specific custom serialization methods should be created so that I can be controlled properly having clear ideas about which fields are exposed.
  4. Generic deserialization features should not be used because they can contain private fields containing sensitive information.

04.Authentication Flaws Mitigation Strategies:

  1. Login credentials should always be sent on encrypted connection and all HTTP requests should be redirected to HTTPS.
  2. Don’t just rely on clients to take necessary security steps.
  3. Make sure the errors on the login page does not reveal sensitive information. Also, the error codes in response to requests should be identical for all.
  4. After a certain limit of login is reached, CAPTCHA verification should get activated.
  5. IP-based user rate-limiting should be used.
  6. Multiple-step verification logic.
  7. An option like 2FA using apps like Google Code Generator.

05.SQL Injection Mitigation:

  1. One of the best ways is to Parameterized queries. It is also known as “Prepared Statements”.
  2. Parameterization works when user input appears as data within the query. Example: clauses like WHERE, INSERT and UPDATE.
  3. Parameterization cannot be used for clauses like ORDER BY and queries like “table names” and “column names”. Input to such queries should be protected by the white-listing method and other logics.
  4. The String in the query must be hard-coded constant and never contain Variable data from any origin.

06.Cross-Site Scripting (XSS) Mitigation:

  1. Filter the user input strictly from the point it is received.
  2. Encode the user data at the point of output in HTTP responses. It might require a combination of encodings like HTML, URL, Javascript and CSS encoding.
  3. Headers like “Content-Type” and “X-Content-Type” should be used to ensure that browsers interpret in an intended manner.
  4. As the last line of defence, use CSP (Content Security Policy) to reduce risk.

07.Cross-Site Request Forgery (CSRF) Mitigation:

  1. CSRF Token should not be predictable. It should be tied to the user’s session and checked before any relevant action executed in the user account.
  2. CSRF Token should be transmitted through POST requests in a hidden field.
  3. Transmitting CSRF Token within a custom request header is more secure as it is not shared cross-domain generally.
  4. The token should be stored on server-side and properly validated.
  5. SameSite cookie attribute can be used to control cookie submission.
  6. SameSite attribute can be used inside the “Set-Cookie” header with values like “Strict” or “Lax”.

08.XML External Entity Injection (XXE)  Mitigation:

  1. Disable dangerous XML features which are not intended to be used.
  2. Disable “XInclude” support and resolution of external entities.

09.Cross-Origin Resource Sharing (CORS) Mitigation:

  1. Web resources with sensitive information should be specified properly in the “Access-Control-Origin” header.
  2. Only trustable sites should be specified in the “Access-Control-Origin” header.
  3. Avoid using a header with “: null” value.
  4. Avoid Wildcards *” in internal networks.
  5. CORS is not a substitute for server-side security policies.

10.HTTP Request Smuggling Mitigation:

  1. Disable reuse of back-end connection. It will send each request over a separate network connection.
  2. Use HTTP/2 protocol for back-end connection. It prevents ambiguity about the boundaries between requests.
  3. Front-end and back-end servers should use the same web server software.
  4. Additional steps can be added like normalizing ambiguous requests from the front-end or rejecting ambiguous requests at the back-end and closing the connection. But these methods are more error-prone.

11.OS Command Injection Mitigation Strategies:

  1. Strict input validation.
  2. Validation against the list of permitted values.
  3. Validation that input is a number.
  4. Validating that input contains only alphanumeric; No other syntax or whitespace.

12.Server-side Template Injection Mitigation:

  1. If it is not a requirement then modifying or submission of new templates should be avoided.
  2. Use a “Logic-less” template engine if possible.
  3. Another way is to execute users’ code in a sandboxed environment.
  4. Deploy the template environment in a lock-down docker container.

13.Directory Traversal Mitigation Strategies:

  1. User-supplied input should not be passed to filesystem APIs together.
  2. If the above condition is not possible to implement then use two-layer defence given below:
    1. The application should validate user input and should make sure it only contains permitted content.
    2. The application should append the input to the base directory and use a platform filesystem API to canonicalize the path. It should verify that the canonicalized path starts with the expected base directory.

14.Access Control Mitigation Strategies:

  1. Don’t rely only on obfuscation for access control.
  2. Use deny access by default and only allow access to resources which need to be public.
  3. Enforce access control throughout the application using a single mechanism.
  4. Audit and test access-control.

15.Securing WebSocket Connection:

  1. Use WebSocket over TLS protocol (wss://).
  2. Websocket URL of the end-point should be hard-coded and it should not include user-controllable data.
  3. Cross-site WebSocket hijacking vulnerabilities can be avoided by protecting WebSocket handshake messages against CSRF.
  4. To prevent vulnerabilities like SQL Injection and Cross-site Scripting, the server and clients end data should be handled safely. 

Don’t forget to have look at Free Courses from Tech-Giants like Google, Microsoft and More – Click Here

You May Also Like…


Submit a Comment

Your email address will not be published.