New answers tagged

-2

just the common internet-noise, get used to it. there will be even more stuff like this hitting your server all the time. just use the search-function and look for "strange logs" to see what i mean.


1

As you already noted, there are two ways to exchange symmetric session keys: through key encipherment or through key agreement (which is based on Diffie-Hellman algorithm). Both algorithms are not used at the same time. For example, Microsoft SChannel client reads bits from server certificate's KeyUsages extension (which is a bit string) and depending on ...


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

AFAIK, some of them are in countries, where single entity (gov) can covertly do whatever it wants on their machines. Yes, pretty many countries are like that today. Sadly, concerning governments, the CA system is not (and never was) secure. CAs are still good for preventing some people and organisations from attacking, just not all.


0

HTTPS only is a bad idea if your site hosts public info, especially if that info is dynamically generated by a CMS. It makes ISP Internet caching and reverse proxy (such as squid/varnish) not work and that can lead to overloaded servers and exorbitant bandwidth usage. If you have a limited number of users this isn't a big deal but it will cripple your ...


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


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

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.


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


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.


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


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


0

You have interpreted the first one correctly. The second one: flow:established,to_server; content:"POST"; nocase; http_method; \ content:"/check.php?tcpc="; http_uri; \ content:!"User-Agent|3a|"; http_header; ... This alerts if: method is POST, URI contains /check.php?tcpc= and it does NOT have a User-Agent. The ! in front of ...


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


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


29

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


-1

You can detect it with the Firefox resource bundle. You just have to be aware of JavaScript programming. The resource:// URI scheme is used by Firefox to call on-disk resources from internal modules and extensions. But some of these resources may also be included to any web page and executed via a script tag. Mozilla developers is not considering the ...


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


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


0

The real answer is that SSL certificates in their current form are comically hard to use. They are so unusable that it threatens the security of certificates, as people take shortcuts to just get stuff done. I say this as somebody who routinely deals with 2-way SSL (PKI certs), the TLS stack incompatibilities that are created by the complexity of the spec, ...


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


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


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.


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


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


0

Is there any sound technical reason to prefer POST? Yes, if there is a "state change" then a safe method should not be used. See RFC7231: Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying ...


0

You can see GET Request Parameters(Query string) in the Address Bar of the Web Browser So you don't want to end up like this http://www.mysupersecuresite.com/login.php?name=me&password=mycoolpassword


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


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


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


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


0

HSTS uses a sandboxed client side 307 redirect, so it does not even hit the server until it's in explicit https mode. A 301 redirect on the other hand is server side, takes resources, time to complete, etc. Also, a 301 stacks up your [chained] redirect count, which is generally attributed to SEO dilution. So HSTS is generally the better choice due to its ...


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


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


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


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


0

If there is a Reverse Proxy Cache in front of this server this could easily lead to cache poisoning attacks. You could build the query with some response headers automatically stored in the cached response like: Content-Security-Policy headers Set-Cookie headers (but usually caches removes theses headers) Transfer-encoding or Content-Length could help ...


0

Instead of trying to fine-tune the behavior of CAPTCHAs on a form, consider that most users hate CAPTCHAs and you should look instead to solve the problem you are really trying to solve. Perhaps you can eliminate the CAPTCHAs entirely, which would make your users much happier than slightly less confusing CAPTCHA behavior. CAPTCHAs are primarily used to ...



Top 50 recent answers are included