Tag Info

New answers tagged

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 ...


0

makes me remember this: char shellcode[] = "\xeb\x2a\x5e\x89\x76\x08\xc6\x46\x07\x00\xc7\x46\x0c\x00\x00\x00" "\x00\xb8\x0b\x00\x00\x00\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80" "\xb8\x01\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xe8\xd1\xff\xff" "\xff\x2f\x62\x69\x6e\x2f\x73\x68\x00\x89\xec\x5d\xc3"; void main() { int *ret; ret = (int *)&ret + 2; ...


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 ...


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 ...


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 ...


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 ...


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) ...


0

Using the HEAD command in telnet against a web server allows a potential attacker to conduct reconnaisance against your web server. Amongst other things the response can reveal what web server you are using and what technologies such as PHP or ASP, possibly with version numbers. The attacker could then use this to go and do some enumeration, which is the ...


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 ...


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 ...


0

It should be possible for you to get the key down to the client without risk that an attacker with access to the network connection can intercept it. That could be down with something like SSL using specific server and client certificates to authenticate each end of the connection. However an attacker with access to the client code (e.g. most mobile ...


0

This is an assumption, but presumably your site is for the most part HTTP, then when it needs to process a payment it becomes HTTPS or forwards to a HTTPS page? If so there is a risk there, as it is possible to fool users into visiting a HTTPS page over only HTTP. For example see http://www.thoughtcrime.org/software/sslstrip/. As m1ke alludes to, you can ...


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 ...


0

It took me a bit of digging to find it, but I found this which seems to answer the question: https://www.djangoproject.com/weblog/2013/feb/19/security/#s-issue-host-header-poisoning Issue: Host header poisoning Several previous Django security releases have attempted to address persistent issues with the HTTP Host header. Django contains code ...



Top 50 recent answers are included