Security Related concern

[Pushpendra Singh Chauhan]

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.

 

 

[Randy Calvert]

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

[Randy Calvert]

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. 

[Stuart Silvester]

@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.

[Pushpendra Singh Chauhan]

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.

[Randy Calvert]

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.