We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

54

Why do we need HTTPS for static content? If we can have a checksum at the end signed by the private key, won't that prove the validity? I think you're setting up a strawman with that question. We don't in fact need HTTPS for static content, and the purpose of HTTPS isn't just to prove the validity of the content. That's just one of several purposes. The ...


21

If you accidentally disclose your password -- either through typing it into the address bar, or in any other way -- it's best to change it. There's no need for any complicated checklist. Simply change that password, everywhere that you used that particular password. This will protect you. Is it absolutely necessary to change your password if you typed it ...


16

Your suggestion is to basically split HTTPS up into two things: Signing-Only and Encryption: Signing-Only prevents an active man in the middle from injecting their own content - such as script tags - and Encryption would protect sensitive data. But who would decide what is sensitive data and what is not? This seems time-consuming and error-prone. You ...


13

Implementing some sort of checksum would work, yes. But using TLS is much easier. It's also generally advised to use standard protocols unless you have a really good reason not to. Finally, https provides a variety of other advantages. Within the bounds of the CA system, you know that you're receiving the file from whom you think you are. And it provides ...


13

There are a few security issues I can think of. Replay and substitution There is nothing preventing a man in the middle from replacing a signed resource with another signed resource (captured previously). For example, I might be able to make a green GO button appear where a STOP button should be, causing you to drive off a cliff. Or I could make it look ...


12

This is partly solved by subresource integrity. You serve the main page over HTTPS, and this includes the subresource metadata/hashes, the subresources can then be fetched over HTTP to be cached by ISP proxies or over HTTPS to be cached by a CDN and you can be confident that the resource is untampered by the intermediaries as long as the hash matches. ...


9

Cryptographic hash functions usually have the property that slightly different inputs generate vastly different outputs. Any collisions should usually have very different input. This property does not apply to most non-cryptographic checksums. Small changes can result in similar checksums, and in some corner cases some small changes can cancel each other ...


7

First of all; officially everything after the # isn't part of the URL with respect to requests and responses. It isn't sent to the server, and it is ignored when retrieving and setting caches. It appears in the URL bar, but isn't not part of the resource's specified location. With respect to the question of how do browsers determine whether to cache pages; ...


7

Cache-Control: private Indicates that all or part of the response message is intended for a single user and MUST NOT be cached by a shared cache, such as a proxy server. Looking at OWASP: Testing for Browser Cache Weakness Browsers can store information for purposes of caching and history. Caching is used to improve performance, so that previously ...


6

This is what TLS is supposed to fix - if the website uses a certificate to identify itself, someone having the old IP address will still not be able to impersonate them. Also, even if you don't cache the entries within Firefox, your own resolver is going to cache them. You cannot count on a DNS change being immediately visible to all clients - so anyone ...


5

SANS first ran an article on the basics of what you are looking for -- a way to detect mimikatz on the network -- https://isc.sans.edu/diary/Detecting+Mimikatz+Use+On+Your+Network/19311/ However, remember that mimikatz is capable of Kerberos attacks -- https://dfir-blog.com/2015/12/13/protecting-windows-networks-kerberos-attacks/ -- as well as PtH attacks -...


5

The solution is to not cache like this. For a start, <? is only one of several ways to inject PHP, including <script language="PHP"> and <?php. Blacklists are always a bad idea. Your caching system doesn't work in the first place in terms of performance because, by the time your PHP serving becomes a performance problem, your disk performance ...


5

First of all, just because you use CloudFlare does not mean that the traffic will pass through the US. CloudFlare currently has 102 edges, and requests will be sent to the nearest one. This is what is called "anycast". So if someone in Europe requests your page the request will go from them to an edge somewhere in Europe, and from there to your origin. In ...


4

Here are some issues about static resources (SR) that I can think of: SR that are not served via HTTPS in combination with cookies that don't have the Secure flag will leak the respective sensitive cookies and also cause browser warnings JS resources that are not served via HTTPS can be modified by an attacker with a privileged network position and can be ...


4

Pragma is deprecated in favor of Cache-Control, but because of its common misuse as a response header there are clients and proxies who will interpret it as such. Past squid versions are an example and starting with 3.2, Squid is advertising and attempting to fully support HTTP/1.1 specifications meaning pragma in a server response has no meaning whatsoever ...


4

Cached pages aren't inherently more secure, as the same page is being sent to your browser. It still renders the website in your browser. If you need to go to a sketchy website, turning off plugins and JavaScript makes it more safe. In Chrome, go to Content settings and add a Deny exception for the site in Plugins and JavaScript. For Firefox, use the ...


4

Encrypting in-memory data stores/caches is generally not done because all the working data is stored in RAM and so will the encryption key at some point and if an attacker has access to the memory of the system, he will have access to the means to decrypt the data or have means to access the data after decryption so it is not providing any additional ...


4

The law is about what you are allowed to store and targets your infrastructure. And the law is intended to give the user control over his data. The client cache belongs to the client's infrastructure in any reasonable definition and already is under control of the user. This may be interpreted differently when you try things like supercookies which stay ...


3

Usual non-cryptographic hashes such as CRC-32 are statistically good, but here what the cache wants to avoid is false positives -- recompilations that are declared identical to a previous one, but are not. A usual non-crypto hash that produces only 32 bits has too high a risk of false positive, simply from its output size, and regardless of its statistical ...


3

It is all down to what "cached" means... Since you mentioned Google Cache, a default cached version, caches the text and load external resources (potentially unsafe): So it is by default no more secure than accessing the webpage directly. If you edit the cached URL however by adding &strip=1, it will be more secure by essence, because the current cached ...


3

Apparently, this topic arouse great interest to many of you. After having done some more research, I presented the CacheBleed attack to a group of scientists last month. Now, I would like to share my results with you and to actually answer my own question. The above three steps of the generic Prime+Probe attack are correct. However, the decisive step is ...


3

The cached page still contains references to the original content (images, scripts and style-sheet files, etc.) so, when you look at the default cached page, your browser will request this content to the original website, possibly along with a "referer" header telling explicitely to the website that you are currently viewing the Google cached version of ...


3

Is this normal Yes, FTP/SSH recon and brute force is pretty common. Welcome to the wild wild web. or should I take action on it? You should definitely take action on it. Is there a reason why you have anonymous FTP exposed? This is highly insecure. The files in your case don't exist, but what if an attacker asks legitimate files like your application ...


3

Using the etag to get the data Knowing the etag alone will not help you with getting the secret resrource, assuming the server is properly implemented. The browser will check with the server to see if the etag is valid (using the If-None-Match header). When Alice makes the request, she will be authenticated so the server should respond with 304 Not ...


3

Browser fingerprinting The issue you are describing is one technique out of many in the field of browser fingerprinting. There are three main types of browser fingerprinting, often related. In order of amount of research, they are: Device fingerprinting, which aims to distinguish individual users. It focuses on finding unique identifiers on a browser when ...


3

Assuming you use windows. The PIN is cached to avoid having to re-enter it. The certificate is on the smart card and cannot be cached as the pin is used to unlock it. I don't think Chrome can cache the pin as it's handled by the credential providers and not the application itself. Relevant info from https://docs.microsoft.com/en-us/windows/security/...


2

S3's access control is not really suitable for functionality. If every instance of the app uses the same credentials to access S3 then the JSON records could be compromised by an attacker who has decompiled the app. if you want to make a change to a user record stored in S3, the change will not propagate immediately. So if you if your application has a ...


2

According to OWASP Application Security any page that can have sensitive information should not be cached if it can be accessed by public shared computers like libraries. https://www.owasp.org/index.php/OWASP_Application_Security_FAQ Any page after the user is logged on is much more sensitive and candidate for no-cache than the login page it self (since ...


2

The login page is not login information; the latter should be cached only with great caution. But the page itself is no secret; everybody can obtain it. Therefore, there is no problem in applying to that page the same caching mechanism as for all other pages. As for extra protection, don't count on it. If the attacker can break through SSL in some way, then ...


2

OpenX Ad Server version 2.8.10 was shipped with an obfuscated backdoor since at least November 2012 through August 2013, remove and install a fresh version of OpenX.


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