Pushpendra Singh Chauhan Posted June 7, 2022 Share Posted June 7, 2022 Hi, The security audit agency found some vulnerabilities. Invision team kindly look into this urgently @Marc Stridgen 1. Source Code Disclosure: The attacker can get sensitive information of application which leads to other chaining attacks. 2. Host Header Injection: : An attacker can perform malicious activity using host header injection. Attacker can control the host header and exploit it using web-cache poisoning. 3.The application transmits the clear text password from Login Page. SeNioR- 1 Link to comment Share on other sites More sharing options...
Solution Randy Calvert Posted June 7, 2022 Solution Share Posted June 7, 2022 (edited) Number one is not “exposing” anything sensitive that is related to the server or app itself. It’s user level info or public knowledge data. None of those fields contain anything that is not already available elsewhere to that user as part of a normal HTTP request (either via header or body values). Number two would be mitigated at the server or via a WAF. That is not a code level thing to check. Number three… encryption in transit is controlled by TLS on your server. The value would not be able to be read by a third party if HTTPS is utilized. Again the only group that can read it is the user for their own data if HTTPS is enabled. The value is not from the database. It’s what is being passed from the form BY the user to your server. You can’t hash/salt it until the server gets it. Once the server gets the data… passwords are stored in the database in an encrypted format with proper hashing/salting. Edited June 7, 2022 by Randy Calvert Matt, Jim M, Meddysong and 2 others 5 Link to comment Share on other sites More sharing options...
Randy Calvert Posted June 7, 2022 Share Posted June 7, 2022 10 minutes ago, Randy Calvert said: Number three… encryption in transit is controlled by TLS on your server. The value would not be able to be read by a third party if HTTPS is utilized. Again the only group that can read it is the user for their own data if HTTPS is enabled. The value is not from the database. It’s what is being passed from the form BY the user to your server. You can’t hash/salt it until the server gets it. Once the server gets the data… passwords are stored in the database in an encrypted format with proper hashing/salting. I was mid edit and my time ran out to fix something. Take two on my last paragraph. Number three… encryption in transit is controlled by TLS on your server. The value would not be able to be read by a third party if HTTPS is utilized. The value in the example above is not from the database. It’s what is being passed from the form BY the user to your server. The user knows what the value is because they typed it. So you’re not exposing anything to the user. If HTTPS is utilized, it also can’t be exposed or attacked by a man in the middle. Once the server gets the data… passwords are stored in the database in an encrypted format with proper hashing/salting. Meddysong 1 Link to comment Share on other sites More sharing options...
Stuart Silvester Posted June 7, 2022 Share Posted June 7, 2022 @Randy Calvert's overview is on the money. I would like to add an extra point though. If you think you've got a security concern, please let us know privately (this can be via HackerOne or our contact form). Please do not post it publicly. Link to comment Share on other sites More sharing options...
Pushpendra Singh Chauhan Posted June 7, 2022 Author Share Posted June 7, 2022 50 minutes ago, Stuart Silvester said: @Randy Calvert's overview is on the money. I would like to add an extra point though. If you think you've got a security concern, please let us know privately (this can be via HackerOne or our contact form). Please do not post it publicly. Thanks will contact form for this in future 1 hour ago, Randy Calvert said: Number two would be mitigated at the server or via a WAF. That is not a code level thing to check. @Randy CalvertCould you guide a little bit about no.2 (Host Header Injection:) how to mitigate this at the server level. it would be a great help. Link to comment Share on other sites More sharing options...
Randy Calvert Posted June 7, 2022 Share Posted June 7, 2022 IPB does what they can with sanitizing user requests. However in terms of someone spoofing headers… Some ways of preventing host header injections: Validate Host headers User input must always be considered unsafe and should be validated and sanitized first. One way to validate host headers, where needed, is to create a whitelist of permitted domains and check host headers in incoming requests against this list. Respectively, any hosts that are not recognized should be rejected or redirected. To understand how to implement such a whitelist, see the relevant framework documentation. When validating host headers, you must also establish whether the request came from the original target host or not. Whitelist trusted domains Already at the development stage, you should whitelist all trusted domain names from which your reverse proxy, load balancer, or other intermediary systems are allowed to forward requests. This will help you prevent routing-based attacks such as a Server-Side Request Forgery (SSRF). Implement domain mapping Map every origin server to which the proxy should serve requests, i.e., mapping hostnames to websites. Reject override headers Host override headers, such as X-Host and X-Forwarded-Host, are frequently used in header injections. Servers sometimes support these by default, so it’s essential to double-check that this is not the case. Avoid using internal-only websites under a virtual host Host headers injections can be used to access internal (private) domains. Avoid this scenario, do not host public and private websites on the same virtual host. Create a dummy virtual host If you use Apache or Nginx, you can create a dummy virtual host to capture requests from unrecognized host headers (i.e., forged requests) and prevent cache poisoning. Fix your server configuration Host header injections are frequently due to default settings, and faulty or old server configurations. Inspecting and fixing your server configuration can eliminate significant vulnerabilities that open the door for injections. SeNioR- 1 Link to comment Share on other sites More sharing options...
Recommended Posts