From the perspective of the client, it does not matter where these headers are implemented; only whether they are implemented at all.
But, from the perspective of deployment, a WAF should be treated only as an additional line of defense and not as the single line of defense. This means that proper input checking should be done in the web application itself ...
No, because the information being leaked is so minimal that an attacker gains no meaningful information from it. If you look at today's server landscape, nginx is currently the most popular web server there is. So even if an attacker would not know for sure what web server you use, they could simply feel lucky and try some nginx-specific exploits.
The real ...
Just for some thoughts, without saying this is a proper recommendation:
Check which levels of flexibility you need - if some of these headers need to be set in special circumstances (eg. depending on the state of your application), you maybe have no chance but to keep them in the application.
If there are multiple apps behind the WAF, can you be sure that ...
You have it the wrong way round. Much like Access-Control-Allow-Origin the purpose is to allow other systems (in this case specifically web-hosted Flash and PDF content) to access your domain. The "remote domain" is you, the "source domain" is who we're defending against.
When clients request content hosted on a particular source domain and that content ...
This is now the default policy for all directives that are absent. This is not as secure as it could be.
Since there is no img-src directive, the value for default-src is used as img-src. This means that images can be loaded from any URL. This doesn't introduce a big security problem, since showing images is relatively benign.
There is also ...
The HTTP response code is unrelated to the existence of an XSS. If you get a 200 (status ok) while trying an XSS then it could be that the XSS was actually successful or that the XSS does not work because the server has sufficiently sanitized the data.
Similar a code of 4xx, 5xx etc could happen without a successful XSS, for example if a web application ...
Frankly, this mail header looks strange for me in several places and I'm not sure if this is because it was actually delivered this way, if it was changed afterwards or if the mails was just constructed:
The Received-SPF and Authentication-Results fields claim to be set from google.com but are located after the Received field for google.com. According to ...
I found something of your interest :
The sending IP address and the SPF validation will give you a very
good sense of whether an email truly comes from the person purported
to be sending it.
The line Received: from mout.gmx.com (mout.gmx.com. [22.214.171.124]) gives you the IP address from where the email is coming from.
Now, there are various websites that ...
To be honest this looks fine. It would be helpful to see the mail itself.
The whole fcmb.com domain is valid. They are not listed on any blacklist.
Those IPs are all valid.
They use emailprotection by trendmicro. They have valid certs by GlobalSign issued for the hostingprovider of their website, Incapsula Inc.
Here is some information on the bank:
Phishing isn't actually the main reason, although the scenario you describe doesn't work if you're trying to trick the user into thinking they're signed into a site and don't know what the site looks like for that user. Phishing isn't just used to steal credentials; it can also be used to trick a user into taking some action within their authenticated ...
You haven't found the IP address of your target server: you have just one of the numerous IP addresses used by Cloudflare servers.
As Cloudflare assigns the same IP address to multiple sites, you need to tell which site you're trying to reach, there is this text in the error page:
A valid Host header must be supplied to reach the desired website.
No, because you can run fingerprinting software to identify the web server software. Each web server comes with some uniqueness, so hiding your web server's name is security by obscurity.
For removing the server header completely, you need to compile nginx yourself.
You can't set those headers, because the browsers ignore attempts to set them. Browsers ignore attempts to set them, because they aren't supposed to be script-controlled. The restriction on letting them be script-controlled is for security reasons. If you could set the Origin header, you could break the security guarantees of CORS. Since the whole point of ...
The answer is almost certainly a solid: No.
The length of time that a client is willing to wait until it receives a response from the server is fully configurable by the client. Either the HTTP library being used by this app has a short time set by default, or the app itself has configured the request to have a short timeout. For an example, see this ...
That is not wrong, but redundant. As you say, if there is a legacy
system involved, then such an approach might be unavoidable.
Effectively what you have an initial authentication, which is later
superseded by authentication from sub-service.
Yes, X-Auth-Token is
an appropriate header for your secondary token.
The only point to consider in this case - what ...
It depends on the header, and on what the library is designed to handle. Let me go through each header and explain if it would make sense or not:
Does specifying Content-Type make sense?
Yes and no. It's certainly nice for the server to tell us that the response is in JSON, but it is by no means a requirement. It would make sense to throw an exception if ...
Reference (borrowed from the answer to the linked question):
Verifying origin with standard headers
This defense technique is specifically proposed in section 5.0 of Robust Defenses for Cross-Site Request Forgery. This paper ...
CSRF for Proxies
It sounds like your service is acting more or less as a proxy for other services. Looking at things from that perspective I would say that the preference is to not perform CSRF protection (which is a stronger statement than suggesting that CSRF protection may not be necessary).
The reason is that if you are not doing anything yourself but ...