Tag Info

Hot answers tagged

3

If the majority of your traffic is personalized data then you should use HTTPS and rely primarily on browser caches. Make use of this cache by setting Expire header and ETag. Additionally, the Cache-Control: no-store advises browsers to not cache the data on a persistent storage, the data can only be cached on RAM. In effect, this is like session cache.


3

If user B is in same network, so he can use ARP poisoning for capturing the data that transfer from user A to the server. This type of attack called MITM ( man in the middle) attack. But if user B is not in the same network, the only way is that installs a backdoor or trojan on the computer of A. Anothe way is that before that user A open web browser, user ...


2

You should use the private directive. Note that content will remain available within the user's browser, even if the Expires header is set as this header does not necessarily force the browser to purge it after the date and time set so it does not meet your session time-out requirement. However, if this risk is acceptable then it may be suitable. You could ...


2

With enough traffic from your internal users, an attacker could map the internal networks of an organization. There might be very low value in this data, however, if DHCP expires IPs quickly, or if the internal network is predictable (or uninteresting) on its own. It would also require a lot of traffic from the network's users to be helpful.


2

I think we should keep things in perspective here. Is visiting a news site over HTTP non-secure or a security issue? Visiting a site over HTTP is fine as long as sensitive information is not transmitted over HTTP. Is visiting this site over HTTP an issue? It might be! If you are authenticated (logged in), the session cookie is transmitted in each request. ...


2

Fast answer No! Acceptable workaround Even an HTTPS connection from IE or Windows XP can't be considered as secured by a normal and even a skilled user. It was a known weak combination long before Microsoft announced its support deadline. Hence I would suggest a 2 steps approach for a webserver architect. Detect the referer, and if it is IE any version ...


2

I'm going to assume that you are talking about HSTS. HSTS is TOFU (Trust on first use). So from the second use onwards, you are protected. But what about that first use? I don't think there's a unified strategy. But here's some ideas: What works today HSTS Preloading: Use a browser that makes use of the HSTS preload lists. (Chrome, Firefox) And hope ...


1

Yes you should be concerned about this. Its a possible side-channel and it reveals information about your system. Some possible defenses (that are being used) are: Use a pseudo random minimum wait delay. (this means that a valid or invalid response will take about the same amount of time) have an invalid response do all the calculation steps of a valid ...


1

I think that Linux uses some increasing delay for invalid logins. For example, if you login with a bad username or password, there's something like a 1 second delay on your first attempt, 2 seconds on your next attempt, 4 on your third, etc... This both hides the calculation delay that you are concerned with as well as slowing down people trying to mine your ...


1

You are asking for an answer from a security point of view. However there is more than one security point of view depending on which threat model you have in mind. If your threat model is an attacker attempting to compromise your server by making requests to your server, I would say it doesn't make any difference how you handle requests specifying an IP ...


1

Yes, it's unsecure. You send your requests and all data in plain text. I am not sure about cookies, but other data is not safe. If somebody make a MITM (Man In The Middle) to you, he can see what you send and what you receive. Also and your ISP ( Internet Service Provider) can see your data which you send to some http web site.



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