The security headers like
x-content-type-options:nosniff
x-frame-options:SAMEORIGIN
x-ua-compatible:IE=edge, chrome=1
x-xss-protection:1; mode=block
should be request or response headers? And why?
All of those headers (like most http security headers) are used by the browser to enable security features in the browser.
Therefore they need to be in the response headers sent by the server to the browser.
It would do nothing to set them in the request header (sent from browser to server) as they are not used by the server.
it should be response header , for example : x-content-type-options:nosniff: This is a security feature that helps prevent attacks based on MIME-type confusion. you can read complete details on Veracode Site, Owasp Site ,
MSDN Site
Related
I have been working on a uni project and I'm getting really stuck on why the cross site authentication cookie from our backend isn't set when I do a CORS request to it from our backend.
Our setup is as follows:
A frontend on https://frontend-domain.com sends a CORS request to https://backend-domain.com with credentials in the post body, expecting a Set-Cookie: auth-token header in the response, if credentials are correct.
The fetch to the backend has credentials: 'include' set.
The backend response includes Access-Control-Allow-Credentials: true and explicitly states Access-Control-Allow-Origin: https://frontend-domain.com. The Allowed Methods header is also correct.
The token cookie in the Set-Cookie header has the attributes SameSite=Noneand Secure, it's domain attribute is Domain=backend-domain.com.
As far as I could find on the mozilla docs or here on stack overflow, these are all the requirements for cross site cookies to work. I expected the Set-Cookie header would make the browser set the cookie, which would then be sent along with all further requests to https://backend-domain.com, given credentials: 'include' is set.
However, the cookie is never set.
Can anyone help me? I am absolutely clueless by now.
Thank you very much for reading and helping!
Edit
I am using Firefox right now.
Here is a screenshot of the request:
And here is the response:
All of the Set-Cookie headers you can see in the response dont result in an actual cookie.
The SameSite attribute of a cookie controls whether this cookie is included in
subrequests (such as the ones made by an <img> or <iframe> element or a Javascript fetch command) to a different origin
top-level navigation requests (which load a new page into the current or a new browser tab).
Details are given here. Note especially the subtly different treatment of navigation with GET and POST ("Lax-Allowing-Unsafe").
Cookies in subrequests (but not top-level navigation requests) may be additionally restricted based on browser settings if they are third-party cookies, that is, if the top-level domains of their origin and the sending web page differ. In other words: Cookies from backend-domain.com count as third-party cookies when a request is made by an HTML page from frontend-domain.com, and this is what caused the issue in your case.
HTTPonly or Secure flag header works on HTTP request or HTTP response?
Most of the time I see it on response.
According to the Microsoft Developer Network, HttpOnly is an additional flag included in a Set-Cookie HTTP response header. Please check https://www.owasp.org/index.php/HttpOnly
If the HttpOnly flag (optional) is included in the HTTP response header, the cookie cannot be accessed through client side script (again if the browser supports this flag).
And It's mitigating the most common XSS attack using HttpOnly
XSS like alert(document.cookie) can be executed if HTTPonly or Secure flag not available in response header, you can set these headers from web application server configuration. Once you set headers user's browser will get these headers in response and browser will deny any java script to get cookie data. So these headers are response.
We have come across an issue in production logs where "Accept-Language" is missing in the http request from the browser. Although I am not able to replicate it so I want to understand any valid use case where any specific browser may send a request without "Accept-Language" header.
Even GET / HTTP/1.0 is a valid HTTP request. You can create one from the telnet client if you wish and it will still return a result from the server!
Accept-Language is a header to aid in content negotiation and is optional. The most widely used browsers send the correct headers, but there may be corporate proxies who may be filtering such headers. You should not rely on this header being present.
If I have configured Access-Control-Allow-Origin: http://mydomain correctly, should it be listed in the response headers if I view them using the web developer plugin? I don't see it. Should it be there?
I have tried viewing the response headers after submitting my post request, and just calling the page.
Background
I need to transfer a couple of values from mydomain to receivingdomain via XMLHttpRequest POST request and am trying to troubleshoot
XMLHttpRequest Page1.asp cannot load https://receivingdomain. No Access-Control-Allow-Origin header is present on the requested resource
If I turn on the Allow-Control-Allow-Extension plug-in my post requests work correctly. However, when this plug-in is disabled, my post requests are being received ok (the data is inserted into the database) - I'm just not getting any result back from the receiving server.
After a few tests, I'm starting to reach the conclusion that a browser does not send a Referer HTTP header when one clicks to a http page from a https one.
What security reason is that for? Is is defined somewhere in the standard?
The HTTP RFC states, in section 15.1.3 Encoding Sensitive Information in URI's :
Clients SHOULD NOT include a Referer
header field in a (non-secure) HTTP
request if the referring page was
transferred with a secure protocol.
So, this is expected / standard behaviour.
Actually it's not that straight forward anymore (2014 onwards), according to this w3c document on referrer policy.
The default behaviour is that browsers will not send referrer information when going from HTTPS to HTTP. However, browsers will send referrer when going from HTTPS to HTTPS.
Also, in HTML5, there is a new meta tag named referrer, that looks like this:
<meta name="referrer" content="origin">
New browsers have already implemented this. So whether or not browsers will send referrer, will depend on this meta tag in the near future. If this meta tag is not included in page's HTML, then browsers will use the default behaviour.
Following are the possible values of content attribute of referrer meta tag:
no-referrer: Referrer will not be sent, regardless of HTTP or HTTPS
origin: Only the origin (main) domain will be sent as referrer
origin-when-crossorigin: Same origin will send full referrer URL and cross origin will send only origin URL as referrer
no-referrer-when-downgrade: This is the default behaviour when no referrer meta tag is provided on the page.
unsafe-url: This will always send referrer, regardless of HTTP or HTTPS
Also, there are some legacy attribute values for referrer meta tag. These are no longer recommended, but used in many sites at the moment:
never: same as no-referrer
default: same as no-referrer-when-downgrade
always: same as unsafe-url
I hope this information will be helpful to someone who just found this post after 2014.
Yes, defined in the standard:
Clients SHOULD NOT include a Referer
header field in a (non-secure) HTTP
request if the referring page was
transferred with a secure protocol
Reason: Sometimes SessionIDs are URL encoded. HTTP Pages can have cross site scripting which steals the session from the HTTPS communication. To prevent this, the referrer is not transmitted on the HTTPS to HTTP transition so that the URL encoded sessin ID can't be stolen.