New answers tagged

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


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


0

You could try running synflood against port 443. The client wouldn't be able to connect, and may fail back to port 80. Just a disclaimer, but I haven't tried this. Anyone want to chime in?


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


0

"What can go wrong": If you do that with an API, then all iOS applications designed for iOS 9 and running on iOS 9 using that API will stop working. It's called "App Transport Security", and unless the developer creates an exception for your domain, http is not accepted, and https with not sufficiently secure connections is not accepted. Since your API ...


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


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


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


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.


0

It's simple =) In no-proxy case you're tracing all the redirects yourself, so it's no problem to handle it. A proxy can be tricky as the proxy itself(not Tor case, but there are programs that behave a bit weird), so the proxy component for your language can be. Especially it happens frequently with HTTP and HTTPS proxies. Use a tcpdump - it will show you the ...


0

how does it differentiate the a normal request from a request through a proxy? Proxy detection is usually based on IP addresses. That is particularly easy for Tor, because the IPs of relay nodes are public. From Instagram's perspective it makes sense to block proxies as a mean to enforce rate limis for their API endpoints. Besides that, there is no ...


0

Sure you can, but it will be a long process to bypass all the rate limits, per-IP limits, e.t.c. But occasionally you will hit it for sure.


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


0

Access-Control-Allow-Origin changes the protection offered to the end user in regards to how the Same Origin Policy handles AJAX responses. If a user is willing to mess around with host files in order to change this protection even further on their own, then the only thing they are compromising is their own security. The header allows another origin to ...


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


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

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.


0

If the user input is reflected verbatim with each request, your method probably does not protect against BREACH. The most certain way to defend django is to turn off Gzip compression. Alternately, you can XOR the token with a different pseudo-random value for each request.


0

I assume that there is an authentication mechanism not visible in the example URLs you have shown us, and that the traffic is protected by SSL. The only time someone can see the request but not the response is in the server logs - do you really store these differently from how you manage your application data? If you do manage access to your logs, since ...


0

Since GET request are more prone to be saved in various logs, it is considered unsafe to place private or confidential information in them. Using an ID is perfectly fine since it is anonymous data. If your user ID is not a surrogate key, then you should create a new one and use it for externally identify the user.


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


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



Top 50 recent answers are included