Hot answers tagged

92

You are right, the regression to HTTP is pointless. Note that all your points apply to one particular kind of attack, where the adversary is able to access the data transport between client and server. That could be the owner of a WiFi hotspot or your ISP acting as a man-in-the-middle, who sits in between you and the server. This can be hard to accomplish ...


22

I would raise the following question: What's the point in having authentication in the application? If all the page contains is public content and verifiable in an outside way (eg. a debian mirror, where packages are with PGP) and your users don't mind a third party scrutinizing what they visit, the page might not need https. But not a login either. ...


8

Your credentials are safe, but Session Hijacking might happen One possibility could have been an attacker might have done a SSL Strip attack while acting as the Man In Middle, If that happens the HTTPS website will be served as HTTP to the victim. But as you have confirmed with the website that they have done it intentionally, so this possibility is striked ...


6

You are totally right. Excluding Google login credentials an attacker can perform a MITM attack and intercept all victim's requests. I suggest to you to communicate them the risks an reimplement the SSL protocol.


6

The reason you see that message is Article 5(3) of Directive 2002/58/EC, as amended by Directive 2009/136/EC, according to which users have to give consent for the storing of information (read cookies) or retrieval of information already stored. Some cookies are exempt from this rule, namely when the cookie is needed for carrying your data over the ...


4

Generally, it is ill-advised to implementing your own session handling. If you can, you would be better off by using a well known and well tested implementation. These are the issues I see in your procedure. User requests password reset How will you handle misuse of this function - will you send one email per reset attempt, or will you implement a ...


3

Kaspersky, like most AV products these days, is performing a local MITM against your secure HTTP traffic. It does this in order to be able to scan payloads in HTTP transactions, be it in the request or the response. In order for this to be done correctly, Kaspersky has to generate its own root CA certificate, and generate spoofed certificates on the fly, ...


2

GET and POST are methods used in basic linking, embedding and in submitting forms. These kind of interactions between sites predate the development of the same origin policy. If the same origin policy would be extended to incorporate POST and GET too then lots of sites would probably break. Therefore any POST and GET which can be created by linking, ...


2

This is just Google Chrome checking if your ISP is doing DNS hijacking. It checks if these random hostnames will resolve to some valid IP (i.e. hijacked to serve "helpful information", often with ads in it) or will be reported as unresolveable. Nothing to worry about. For more details see Chromes startup random DNS queries ... or Unusual HEAD requests to ...


2

It's name says "allow" from which I understand that if I make a request from an "Origin" that is not allowed the request should fail. That is right (depending on the request). But disallowing a request is not a property of CORS, it's because of the same origin policy. CORS isn't really a header meant to secure anything, it's a header meant to weaken ...


1

This could give rise to an information leakage vulnerability. Say your whole site is served over HTTPS, without DNS prefetching disabled. There may be certain pages on your site that reference other external resources. For example, imagine a banking website that customers can login to, and that the page for managing mortgages has some external links unique ...


1

I can't comment on this specific scenario as there are unknowns such as rate-limiting by the server (see comment by JonasCz), entropy of the serial keys, etc. Here is a general approach to considering this when protecting your own systems. Each of the ? in the serial key can take one of a number of values as defined by an alphabet. For example, binary ...


1

CORS policy limits what code loaded from site A and executed on your browser can do with site B, i.e. limits what cross-origin requests can do. It is not to restrict what can be done with site B in general, i.e. it cares only cross-origin requests and does not provide any kind of authentication control. You are right that you could in theory just modify ...


1

The Authorization: <type> <credentials> pattern was introduced by the W3C in HTTP 1.0, and has been reused in many places since. Many web servers support multiple methods of authorization. In those cases sending just the token isn't sufficient. Sites that use the Authorization : Bearer cn389ncoiwuencr format are most likely implementing ...


1

Long before bearer authorization, this header was used for Basic authentication. For interoperability, the use of these headers is governed by W3C norms, so even if you're reading and writing the header, you should follow them. Bearer distinguishes the type of Authorization you're using, so it's important.


1

No, this approach is not widely used and here's why: If the client hashes the password and sends this to the server, then doesn't that hash become "the password"? As an attacker, can't I just intercept the hash and use that in a replay attack? You said "A salt can be added also". This one actually is done in some protocols, when you add in a random value ...


1

IMHO, your key problem is that you are not validating the content being uploaded. Since we are only talking about JSON and CSV here, its trivial to write code to validate these. It won't catch all the issues, but it will get most of them. And at least you can tell the uploading user they've made a mistake at the time they are uploading - rather than telling ...



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