Tag Info

Hot answers tagged

30

No. Relevant quote from the link: HEAD Asks for the response identical to the one that would correspond to a GET request, but without the response body. This is useful for retrieving meta-information written in response headers, without having to transport the entire content. If you disabled it, you'd just increase your throughput cost. A person ...


11

Everything Parthian said was spot on. HEAD requests are a like a 'short' GET request that avoids the network extra traffic and potentially the rendering overhead of a GET request. There are a variety of reasons you, your browser, or your search engine may want to do a HEAD request. Some websites may just be pulling meta information off you, and your ...


5

Yeah, if you are describing it accurately this is completely broken, to the point of useless. The initial AES key is compromised by being in the app, anyone with the app has access to the AES key. If this is global, then it is well and truly screwed, if it is unique to each application, there may be a small sliver of hope. The SHA-1 is completely ...


4

Well, the AES key embedded in the library is completely useless, and there seems to be no validation of the server side. I see many problems with this scheme. Anyone with access to the Android library can extract the AES key. Sending a hash of a static value over plain HTTP is the same as sending a password over plain HTTP. Anyone can grab it from ...


3

It's often not only the case that "payment information" is the only sensitive information. If your portal requires some sort of "login" (which it undoubtedly does), you allow many parties in between (Internet Cafe owners, ISP's, "hackers", employers, govermenments, ...) to see these credentials and take over the account. If your portal has anything in ...


2

Whether traditional "protections" for sensitive data in desktop RAM (e.g. SecureString) are really needed or not, is debatable. When attackers can read the RAM contents, they already have a lot of control on the machine. We can still justify some proactive measures in the following sense: RAM in a machine may leak to disk, through virtual memory. The ...


1

User-agent strings do provide the companies running web servers with useful information. If they're contemplating introducing web site features or content they want to know if the majority of their user base have browsers that support that technology. They can look at the user-agent strings logged in the past month or two and get a sense of what browsers ...


1

Since all the requests fail with the "404 Not Found" status, try to create a custom 404 error page that will log everything (all headers, the request, the user's session) and debug this, see if the actual requests come from just a few users with a busted web browser (virus, trojan etc. on the client machine), from all the users, just from users that are ...


1

You seem to have the basic user data covered, but I'm not sure why try to isolate it like that. I would run each user's browser instances with an in-memory home directory/storage area. Then when the process terminates, all of the data is destroyed, no risk of leaving anything behind. Headless Webkit like PhantomJS provide flags specifically to move these ...


1

"Does doing X improve the security of my system?" -- this is a bad way to approach these issues. "Does doing X improve the security of my system enough to justify the costs?" -- is the right question to ask. Does blocking HEAD requests improve the security? Yes, by about .01%. Flaws in the code that handles HEAD requests would be harder (or impossible) ...



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