Hot answers tagged

41

Let's look at the scenario with a 301 redirect first. The victim sends a request to http://example.com (as pointed out in comments, this could because of SSLStrip or because the user just entered example.com in the URL bar and browsers default to HTTP). If there is no MitM attack they get a 301 response back, and is redirected to https://example.com. But if ...


28

HTTP Strict Transport Security (HSTS) is designed for security. HTTP 301 Moved Permanently is used for URL redirection. The 301 redirect is an important part of deploying an HTTPS website. As part of the HTTP protocol, it is supported by more browsers than HSTS. It serves as the primary means for upgrading a plaintext connection to HTTPS, updating search ...


28

This is a DNS resolution trick that could also be performed using non-http protocols but in this case is performed by using random hostnames and zero-pixel images via http. Look at the source code on the page and you will see a series of random 10-character subdomains requested for several URL's. These are very unique hostnames which neither your computer ...


12

I didn't know about this. Extremely interesting. It seems to work by trying to generate connections to long random subdomains that it controls, and it can probably collate the domain resolution requests from the calling DNS server. Fig 1: List of requests initiated by the browser that failed Under the hood it's the standard tracking using a zero size ...


8

I did not know about this until I read the link you posted, so do not view this answer as authorative. I would recommend you to take the precautions listed under "Immediate Mitigation" now, until you are completely sure you are not affected. First, how does this vulnerability work? This is a short form of the PHP example explained under "How it works": ...


7

The full URL is protected by the end to end encryption of HTTPS, but the target IP and hostname (the full name of the host, i.e. FQDN, i.e. something like www.example.org) are not. Thus the router could get the name of the host you visit but not the full URL (i.e. not the path after the hostname): https://www.example.org/some/secret/page.html |-- ...


7

No confidential data should ever be sent via GET. The data may be leaked or stored by: referers if you link to a different page after a login your server logs which is an issue if these logs are ever available, for example via LFI, wrong server configurations, backups, etc. browser histories which is an issue if multiple people use the same browser - eg ...


7

Is it possible to perform MITM on HTTP POST? HTTP is not encrypted, so if you "get in the middle" you can read the communication and modify it. You can get in the middle by e.g. hacking a router or cutting a cable. Your ISP is already in the middle and can read your HTTP communication. This is true for all HTTP methods - POST, GET, etc. Is it possible to ...


7

First of all, some old browsers don't support HSTS, so you still need to redirect HTTP to HTTPS, set the secure flag on all cookies, etc. Now, with that said... In addition to the fine reasons listed above (though @anders' answer really ought to have mentioned SSLStrip, since defeating that exact attack is one of the main purposes of HSTS), there's another ...


6

You should use POST for any state-changing action. If you save the content of the form, or use the form to send an e-mail, you should use a POST. There are several reasons why this is more secure: CSRF is easier with GET requests than with POST requests. With GET requests you can simply send someone a link. With a POST request an attacker needs to have a ...


4

It is as strong as the SSL configuration of your tunnel between your laptop, and the VPN gateway. All traffic now goes through the tunnel to the VPN gateway where it reaches out to the Internet. The VPN gateway will then ferry the response back to you.


4

Does encrypting HTTP header value provide additional security? There is no general response for this but it depends on what exactly you are doing and what kind of "additional security" you aim for. In your case it looks that you just replaced a plain text password with an encrypted password. Unless you have some replay protection baked into your unknown ...


3

It is not possible to "trick" the server, but there are a couple of caveats here. First, it is still possible to set up another site in IIS with a binding that will accept HTTP requests, so you need to be aware of the configuration of any other sites hosted on this server. Second, this configuration means that if people attempt to visit the site ...


3

The ISP can intercept traffic in any number of ways, from a proxy (like you suggest, though I would suspect a transparent proxy), to a span port on a switch. If they have control over a link in the chain between you and the Internet, they can see anything that passes through it. If it's encrypted data, the ISP can use an SSL inspector (like this), but that ...


3

If you really need to use authentication with plain text (HTTP) then you should make sure that sniffing the credentials will not compromise these. While sniffing is easy with basic authentication, a properly done digest authentication (i.e. with nonce to defend against replay attacks) is much better. Unfortunately with digest authentication you need to save ...


3

The key thing to note is that the Same Origin Policy for cookies is more lax than the Same Origin Policy elsewhere. That is, there is not a single secure channel for cookies, they are the same origin: Client ----Plain HTTP----> Server Client ---------HTTPS----> Server Of course the Secure Flag can be set so a cookie value can be set to only transfer ...


3

It is actually even safer. Conventional HSTS only takes effect after the first request to the site, and until the user clears his browser's cache (each browser may handle this differently but I assume clearing all browsing data should also delete the HSTS list), and I believe HSTS does not persist between non-private and private browsing due to privacy ...


3

Yes, it depends how that GET/POST request is handled on the receiving party, i.e the client. While explained in another thread "Yes, you can get a virus just by visiting a site in Chrome or any other browser". This also counts for any client. In this case: the program that's handling the response from your web request. No matter if that's a browser, CLI ...


2

I don't see how there could possibly be a security risk or other vulnerability as a result of implementing the feature you suggest. The reason is simple: since there is no security risk or other vulnerability to not having a CAPTCHA in the first place (with the possible exception of a DOS attack if the action the CAPTCHA protects is a slow action), any ...


2

If the concern is just as far as the WiFi hotspot and the users who are connected to it, then as long as you are connected to the VPN, the traffic should be encrypted and cannot be viewed by any other WiFi user. There are some concerns however, on the type of VPN used, which encryption method it is using, and so on. Also, I think the biggest concern would ...


2

If you cannot setup user accounts or any other way of identification, which is best practice for every API, you are left with the following: Collecting metrics of number of requests per IP, Subnet, AS, Country Throttling proportionally to the usage while trying best effort not to compromise users who do not abuse the system and providing enough quota to ...


2

No - if there is no http binding, IIS will not accept an HTTP request. On 443, it will attempt to negotiate a TLS/SSL (depending on configuration) connection, if it cannot, the connection will fail. https://msdn.microsoft.com/en-us/library/ff720335.aspx Relevant quote : " By enabling SSL in Microsoft® Internet Information Services (IIS) 7.5/7.0, the [...


1

The JDK is offered over HTTP because they also offer a hash for you to confirm over secure channels. Since the hash is over a secure channel, if that hash can't be confirmed you shouldn't use the download. The fact that the part of truth(the hash you check against) is delivered securely means they can offer it over HTTP because you will be able to securely ...


1

No because the browser dont change anything in the request when sending it over https (It will only encrypt it additionally). An attack with e.g. XSS will work exactly like it would work with http. https only prevents from another type of attacks like man in the middle reading the session.


1

TLS is an end to end encryption which means that the traffic between the client and the server is encrypted and can't be accessed by someone performing a MitM attack for example. This does not protect your server in any way it only protects the data that is transmitted. So yes it can be exploited through http aswell as through https.


1

In theory you could use AJAX with a JavaScript implementation of RSA encryption, essentially recreating what the HTTPS/TLS connection would normally do for you from an encryption and key exchange standpoint. It gives you an alternative to storing the password in plain-text server-side as HTTP Digest Authentication (using nonce) would require. Also a ...


1

The sugCls.handleContent method code is here starting on line 1263: https://github.com/liigo/html-parser/blob/master/test/testfiles/sohu.com.html You can see that it does some interesting slicing and dicing to extract parts of the string it is passed. To de-obfuscate, one would need to follow each step manually, run the command in its intended context and ...


1

Command line tools shouldn't be vulnerable to POODLE. The reason is that POODLE is a cross-domain attack where the attacker can send cross-origin requests to the vulnerable endpoint and then use their Man-in-the-Middle/eavesdropper position to read cookie data sent with the request. An attacker can run Javascript in any origin in a browser and cause ...


1

I would start by finding out which SSL library it is using. I wouldn't be surprised if it used (maybe embedded) an old openssl version, in which case there would be a number of vulnerabilities to take into account that could be easily extracted, not just poodle. As pointed out by schroeder, you could launch a webserver that doesn't speak anything newer ...


1

By default you aren't able to do so. In every network that is by any sense modern switches are used. Switches don't deliver all packets to everyone on the network like hubs did. Anyway you can redirect another persons traffic by perdorming a MitM Attack. The most common MitM Attack is ARP spoofing and in my exprience this will work in most networks out ...



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