HTTP Referer changes

[Saiprasad Raut]

Hi,

In my organization, we use IBM Security AppScan Enterprise for APP scans. Since this is licensed tool, it is run only on the QA environment by security team. Developers get the scan report only when the InfoSec team sends the QA test report. I am planning to use ZAP in the dev environment so that developers can get vulnerabilities addressed during development only.

Today I saw following vulnerability in the IBM APP scan report which is related to HTTP header REFERER change:

Risk(s): It may be possible to steal or manipulate customer session and cookies, which might be used to impersonate a legitimate

user, allowing the hacker to view or alter user records, and to perform transactions as that user

Fix: Validate the value of the "Referer" header, and use a one-time-nonce for each submitted form

Request/Response:

POST /Directory/Controller/Controller HTTP/1.1

Accept: application/json, text/plain, */*

Content-Type: application/json;charset=utf-8

Referer: http://bogus.referer.ibm.com

Accept-Language: en-US

User-Agent: Mozilla/4.0 (compatible; MSIE 9.0; Win32)

Host: FQDN

Connection: Keep-Alive

Cache-Control: no-cache

In this vulnerability, IBM APP Scanner tried to change the Referer Header and showed the result that it is not handled in the application.

I ran the ZAP tool today, but it did not show me the same vulnerability in there for the same codebase.

How can I make sure that this scenario can be covered during the active scan in ZAP?

Thanks,

SAI

[kingthorin+owaspzap]

I believe you're misreading the report. Chances are the issue at hand is a CSRF vulnerability.

Counting on referrer checking to protect against CSRF is a rather weak mechanism for CSRF protection so there is a chance that the finding is a false positive. (As other recommendations include use of tokens which may be either transaction or session specific.)
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet#CSRF_Prevention_without_a_Synchronizer_Token

ZAP does have a CSRF Token scan plugin in the Beta quality active scan package.
https://github.com/zaproxy/zap-extensions/wiki/HelpAddonsAscanrulesBetaAscanbeta

[Colm O'Flaherty]

I've seen this finding in appscan results, but as you point out, it's a pointless check, since the referrer is so easy to check. I ignore it.

Personally, I don't see much merit in adding this check in zap, unless someone is interested in it from a purely compliance point of view, rather than from the point of view of knowing about genuine risk.

--
You received this message because you are subscribed to the Google Groups "OWASP ZAP Developer Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zaproxy-devel...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[johanna curiel curiel]

Hi Saiprasad,

It all depends if the referer header field is being used by the application and being validated.

Some developers use the referer as a 'way' to check and validate a request, for example a call to an api. If the expected request header field, in the case the referer does not come from an expected domain source, the application will not process the request. However some applications do not validate this field and per se that does not mean a vulnerability, only if the entire validation of a request depends of it. 

In this specific case, are developers using the request header field 'referer' to validate the request?

Just keep in mind that these fields are easy to manipulate and therefore no developer should be using this alone as a form to validate a request.

Cheers

Johanna

--

Johanna Curiel 

OWASP Volunteer

[Saiprasad Raut]

Thank you all for the inputs.

Developers are already using the hidden field tokens to prevent CSRF. Even I had the feeling that this is false positive but wanted your opinions.

Johana - Developers are not validating based on Referer header. Instead they have used token in hidden field.

Regards,

Sai