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:
- Disable caching if not required.
- Restrict caching to static responses and make sure the version details can’t be tricked by the attacker from the back-end.
- If you are using third-party technology then make sure you understand its security implications.
- Check the headers supported by CDN (Content Delivery Network).
- Continuously track client-side vulnerabilities and apply the patch.
02.Information Disclosure Mitigation Strategies:
- Make sure the internal team understands which info is considered to be sensitive.
- Avoid adding sensitive comments in the Static Code. If it’s necessary then make sure you remove it after the task gets completed.
- Use generic error codes as attackers can get clues from the behaviour pattern of the application.
- Remove sensitive information from Github like testing code, API keys, default credentials etc.
- Understand third-party security implications and disable features which are not required.
03.Insecure Deserialization Mitigation Strategies:
- Deserialization of user input should be avoided.
- The digital signature should be used to check the integrity of data at the beginning of the deserialization process.
- Class-specific custom serialization methods should be created so that I can be controlled properly having clear ideas about which fields are exposed.
- Generic deserialization features should not be used because they can contain private fields containing sensitive information.
04.Authentication Flaws Mitigation Strategies:
- Login credentials should always be sent on encrypted connection and all HTTP requests should be redirected to HTTPS.
- Don’t just rely on clients to take necessary security steps.
- 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.
- After a certain limit of login is reached, CAPTCHA verification should get activated.
- IP-based user rate-limiting should be used.
- Multiple-step verification logic.
- An option like 2FA using apps like Google Code Generator.
05.SQL Injection Mitigation:
- One of the best ways is to Parameterized queries. It is also known as “Prepared Statements”.
- Parameterization works when user input appears as data within the query. Example: clauses like WHERE, INSERT and UPDATE.
- 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.
- The String in the query must be hard-coded constant and never contain Variable data from any origin.
06.Cross-Site Scripting (XSS) Mitigation:
- Filter the user input strictly from the point it is received.
- Headers like “Content-Type” and “X-Content-Type” should be used to ensure that browsers interpret in an intended manner.
- As the last line of defence, use CSP (Content Security Policy) to reduce risk.
07.Cross-Site Request Forgery (CSRF) Mitigation:
- 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.
- CSRF Token should be transmitted through POST requests in a hidden field.
- Transmitting CSRF Token within a custom request header is more secure as it is not shared cross-domain generally.
- The token should be stored on server-side and properly validated.
- SameSite cookie attribute can be used to control cookie submission.
- SameSite attribute can be used inside the “Set-Cookie” header with values like “Strict” or “Lax”.
08.XML External Entity Injection (XXE) Mitigation:
- Disable dangerous XML features which are not intended to be used.
- Disable “XInclude” support and resolution of external entities.
09.Cross-Origin Resource Sharing (CORS) Mitigation:
- Web resources with sensitive information should be specified properly in the “Access-Control-Origin” header.
- Only trustable sites should be specified in the “Access-Control-Origin” header.
- Avoid using a header with “: null” value.
- Avoid Wildcards “*” in internal networks.
- CORS is not a substitute for server-side security policies.
10.HTTP Request Smuggling Mitigation:
- Disable reuse of back-end connection. It will send each request over a separate network connection.
- Use HTTP/2 protocol for back-end connection. It prevents ambiguity about the boundaries between requests.
- Front-end and back-end servers should use the same web server software.
- 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:
- Strict input validation.
- Validation against the list of permitted values.
- Validation that input is a number.
- Validating that input contains only alphanumeric; No other syntax or whitespace.
12.Server-side Template Injection Mitigation:
- If it is not a requirement then modifying or submission of new templates should be avoided.
- Use a “Logic-less” template engine if possible.
- Another way is to execute users’ code in a sandboxed environment.
- Deploy the template environment in a lock-down docker container.
13.Directory Traversal Mitigation Strategies:
- User-supplied input should not be passed to filesystem APIs together.
- If the above condition is not possible to implement then use two-layer defence given below:
- The application should validate user input and should make sure it only contains permitted content.
- 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:
- Don’t rely only on obfuscation for access control.
- Use deny access by default and only allow access to resources which need to be public.
- Enforce access control throughout the application using a single mechanism.
- Audit and test access-control.
15.Securing WebSocket Connection:
- Use WebSocket over TLS protocol (wss://).
- Websocket URL of the end-point should be hard-coded and it should not include user-controllable data.
- Cross-site WebSocket hijacking vulnerabilities can be avoided by protecting WebSocket handshake messages against CSRF.
- To prevent vulnerabilities like SQL Injection and Cross-site Scripting, the server and clients end data should be handled safely.