Hot answers tagged

130

The common web application attack vectors don't apply to a strictly static website. Without interactive elements there are no accounts to hijack or cookies to steal. Nonetheless, you should provide your visitors with encrypted access - even if you're not hosting delicate content. TL;DR Use HTTPS with HSTS to ensure some degree privacy and the integrity of ...


32

HEAD is not dangerous in itself, and it does have legitimate uses. The problem is with Java EE. It has a way to set security constraints using web.xml files - but those are only applied to GET and POST, not to HEAD. This means that it is can be possible to bypass authentication using HEAD. There is more information about this and other issues in this paper ...


30

HTTPS Strict transport security Certificate pinning These protect the transport of the data against sniffing and against manipulation. This protection is not only for the request from the browser but also for the response and thus makes perfectly sense even for a static site. Content security policy If you don't include content from any ...


27

When mail is sent via SMTP, there are two separate places this sort of information goes, the Envelope (things that are set with SMTP commands) and the Header (the first block of text under the SMTP Data command, ending with a blank line). So, for example, here is an SMTP transaction where the Envelope disagrees with the Headers. The message will get ...


26

Checking headers off a list is not the best technique to assert a site's security. Services like securityheaders.io can point you in the right direction but all they do is compare against a list of proposed settings without any context about your application. Consequently, some of the proposals wont't have any impact on the security of an API endpoint that ...


25

It's a lot of work. Not only that, but it's a lot of work that your (legitimate) users will never see or benefit from. Most people would be willing to trade off the nebulous risk of deterring a small subset of hackers (realize that APT hackers, in particular, wouldn't be dissuaded and might even find an extra way into your system if you do something wrong ...


24

Emails, sent through SMTP, have no way of "self-destructing" internally built in to them. They're basically just text files that hang around for eternity until all copies are manually deleted. The fact that you still have the email's headers is proof enough; if messages could self-destruct, their entry would be entirely removed from your mail client, as if ...


24

Note: I like honeypots a lot but to answer your question some negative aspects include: You are not reducing your workload. You are increasing the amount of signals you have to process. You are increasing your operating costs. You are taking time away from other security activities which may otherwise help protect actual data & services. You may be ...


20

Presumably you mean the following four: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.63 Safari/537.36 most Web browsers use a User-Agent string value as follows: Mozilla/[version] ([system and browser information]) [platform] ([platform details]) [extensions]. Mozilla is a byproduct of browser wars. ...


11

To understand this, one first needs to understand what a cross-site request forgery is. A Cross-Site Request Forgery is when the attacker has some script or embedded media on a website they control which makes any visitors to that website request a resource from a different site. That request appears to that other site in the context of the user. I could, ...


10

It's important to include the Vary: Origin header to prevent caching. The header indicates that the response is in some way dependent on the origin and should therefore not be served from cache for any other origin. If the header is missing, cache poisoning attacks might be possible as explained in the article by the example of XSS via a reflected custom ...


7

Couldn't the attacker just spoof the referrer header No, they can't. It is obviously not possible when submitting a form (or the various GET methods such as image tags or url in CSS), and it is not possible via XMLHttpRequest either, as per the documentation. That being said, I would suggest using a token instead, as checking the referer may be bypassed ...


6

Checking the Origin header prevents a WebSocket from being used by another website that the user is also visiting (e.g. to extract data). As per the link: WebSockets are not restrained by the same-origin policy This is because the protocol upgrade request will have access to the user's cookies, so if you're not checking the origin the request could have ...


6

Not really, your understanding seems to be correct. Pretty much every web browser (and most other HTTP clients) will send a user-agent string, so arguably any request that arrives without one is pretty sketchy-looking. On the other hand, it costs basically nothing to send one (for example, with curl, use the -A argument) and is not guaranteed to have ...


6

The HTTP header Content-Security-Policy can be used to protect from loading the page in an iframe. In this case, its value is set to default-src 'self' *.xyz.com which means that only the current domain, and *.xyz.com can load this page in an iframe. That HTTP header has other uses like protecting from XSS attacks. You can find more information on the ...


6

The ETag header is used for effective caching of server side resources by the client. The server send an ETag header in the HTTP response to some string and the client caches the response content and associates the string given in the ETag header with it. If the client wants to access the same resource again it will send the given string within some If-None-...


5

The Origin header on it's own is not always enough (it's only sent on POST and CORS requests, but what you have is a GET request), but the Referer and Origin headers usually is (I'll include an example where they aren't sufficient at the end). By default, Firefox does send the Referer header for same-origin requests. This is in-part why OWASP recommends ...


5

No. It is trivial to change the value of the host header, but, depending on your server set up, this may cause the site not to work as intended. In particular, if you are using name based virtual hosts, the web server will look at the host header to determine which site (of many) to load, and (usually) default to the first defined one if it doesn't ...


5

If you can configure your email client to ensure text is the only thing you are copying, you'll be fine, but most commonly used modern mail clients understand macros, formatting, meta-data etc., so cannot be considered safe unless you can fully control that configuration. To be honest, unless you know exactly how the email client you use handles data (and ...


5

There are so many things to consider while you are planning for website and especially when it is your business website you always need to pay extra attention on it. However static website tends to have less number of risks than other sites but still it should have followed important security aspect as you have mentioned above. The details given here is only ...


4

I doubt that this can be done in the mail application itself. But since you own your own domain, you might run your own mail server and some allow you to change the mail headers. If you use postfix take a look at header_checks. But note that mail clients leave more footprints than just X-Mailer. You can also distinguish clients by the other headers, ...


4

The host header will be the hostname of your web server, and is only used in HTTP requests by clients. It can not be used to validate if the source is authorized to upload images or not. I would develop a login mechanism to which users can authenticate (possibly with a directory service, as mentioned by Matthew) and if authorized, upload new pictures. Deny ...


4

For testing and developing I allowed all Headers. ... It is not very clear what you mean here (maybe be more specific and do not only dump the config) but... Header set Access-Control-Allow-Origin "*" Header set Access-Control-Allow-Credentials "true" It is definitely not a good idea to allow cross origin access from everywhere. And it is ...


4

First, the attacker can't always spoof the content type. For example, if your REST API supports a web app that uses cookies to hold session tokens, an attacker may try using CORS (cross-origin XHR) or auto-submitting HTML forms to attack users of your service when the victim visits the attacker's page. If making a cross-site request from the attacker's site (...


4

Is there any way to prevent this? Yes and no. You can't prevent email from being spoofed. But you can use electronically signed emails, and you can advise the IT staff to start using DKIM or similar, to prevent such emails from being accepted. After that: a non-DKIM or non-signed email will be considered a forgery and rejected. users will need to send ...


4

You should only specify the origin header in your request. The application will respond with the Access-Control-* headers. Try only specifying the origin header and see what the result looks like. As far as if the headers are not returned at all, the web server doesn't have to respond with a CORS policy. If it doesn't then the browser will not allow cross ...


4

[from comment] ... IE was not working, but, does ie11 even support this header? According to can i use content security policy there is only partial support in IE11: only the sandbox directive is supported and the header needs to be specified as X-Content-Security-Policy. Thus, no support in IE11 for what you are trying to do.


3

the client browser will first try the default, un-encrypted HTTP connection, potentially including your Authorization header if the browser has got this details. I think this assumption is wrong: The browser distinguishes between http:// and https://, i.e. credentials entered on https:// will not be included when accessing http:// and vice versa. This means ...


3

As I currently know, the HTTP Host Header can be viewed in plaintext by anyone monitoring my network (when visiting HTTPS sites) and I would like to mitigate this as much as possible. This is wrong. The HTTP Host header is part of the HTTP protocol and with a HTTPS connection all of the protocol is encrypted with SSL/TLS. Thus the host header is only ...


3

Modern Smart phones embed GPS coordinates into pictures. http://www.howtogeek.com/211427/how-to-see-exactly-where-a-photo-was-taken-and-keep-your-location-private/ This is often how sought out individuals are found and detained because they take photos with their phones unaware the photo contains the location as well. It all depends on the software/...


Only top voted, non community-wiki answers of a minimum length are eligible