Hot answers tagged http
114
You can have some serious fun playing with printers, photocopiers and other such devices - even UPSes. Security is usually an afterthought at best, if not totally absent.
Stuff I've seen:
Default credentials used everywhere, and web-based config panels storing passwords in plaintext, often within a generated config file. I've never seen anything better ...
37
I personally think you're doing alright. As long as your underlying login method is secure, add as many obscurity layers as you want.
I have worked with some clients that wanted the exact thing you're trying to achieve. I've always used one of these two methods:
Cross-Site login form: A local .html file that has a login form submitting to the ...
35
Despite what you may think, you actually were using HTTPS. This is perhaps an over-simplification, but here's more or less what happened:
When you accessed the website with http:// as the protocol in your Address Bar, you effectively told your computer "Make a request for this webpage, from this server, and send that request to port 80 on the server". If ...
34
There are a few issues with HTTP Basic Auth:
The password is sent over the wire in plaintext.
The password is sent repeatedly, for each request. (Larger attack window)
The password is cached by the webbrowser, at a minimum for the length of the window / process. (Can be silently reused by any other request to the server, e.g. CSRF).
The password may be ...
30
From a security/implementation perspective, there shouldn't be any need to disallow characters apart from '\0' (which is hard to type anyway). The more characters you bar, the smaller the total phase space of possible passwords and therefore the quicker it is to brute-force passwords. Of course, most password-guessing actually uses dictionary words rather ...
28
SSL/TLS has a slight overhead. When Google switch Gmail to HTTPS (from an optional feature to the default setting), they found out that CPU overhead was about +1%, and network overhead +2%; see this text for details. However, this is for Gmail, which consists of private, dynamic, non-shared data, and hosted on Google's systems, which are accessible from ...
26
An encrypted connection is established first before any HTTP requests are performed (e.g. GET, POST, HEAD, etc.), but the hostname and port are visible.
There are many other ways to detect which sites you’re visiting as well, for example:
your DNS queries (i.e. they’ll see the IP request for secure.logmein.com)
via network monitoring (e.g. ...
22
This is explained in their page on SSL proxying, perhaps not with enough explanations.
A proxy is, by definition, a man-in-the-middle: the client connects to the proxy, and the proxy connects to the server.
SSL does two things:
It ensures the confidentiality and integrity of the established connection.
It performs some verification of who you are ...
20
HTTP 200s can be awesome for an attacker when he is requesting URIs that should be protected by authorization (http://cwe.mitre.org/data/definitions/862.html).
Attackers pay notice to HTTP 500s – they often lead to offensive success. Observing lots of HTTP 500s can be interesting. If the app likes to redirect (HTTP 302) upon errors, then lots of HTTP 302s ...
20
Yes, you're on the right track! But things actually work a little bit differently than you outlined.
In particular, Steps 4-8 are not quite how SSL works. SSL works a little bit differently. Here is how it actually works (I'm going to make some small simplifications, but this should get the gist of the idea right):
The Gmail server sends your client a ...
20
Because HTTPS is not very well suited to securing downloads of large public files. For this use case, it's slow and not that useful. There are reasons for not using HTTPS well beyond incompetence or unawareness.
HTTPS requires more resources on the server. Google mail got it down to a 1% overhead and a 2% bandwidth overhead, but this is for a very different ...
19
Yes, that last someone is correct, in addition to encryption (confidentiality) HTTPS gives you the assurances that the form is coming from where you think it is (authentication), and that it has not been interfered with in transit (integrity). Without HTTPS the form could be modified by a MITM as described.
It'sNot using HTTPS for this is simply bad ...
19
The website seem to be be only checking the User-Agent. I tried the following
wget --user-agent="Mozilla/5.0 (Windows NT 5.2; rv:2.0.1) Gecko/20100101 Firefox/4.0.1" "http://tfdesignsandpcrepair.com/dinwnle.php?get_info=ss00_323" -O file.zip
and it seems to be working
One possibility is that you might have tried so many times without a valid User-Agent ...
18
Short answer. Yes, blocking requests with an off-site Referer: header might have some security benefits, but I do not recommend that you implement it. The usability costs are significant and outweigh any security benefits.
I feel that, as security professionals, our job is not just to recommend defenses that people should implement -- it is also to ...
15
While there are great answers already given, I believe that one aspect is overlooked so far.
Here it is: Plain HTTP is the default protocol for the web because the majority of information on the web doesn't need security.
I don't mean to belittle the question, or the security concerns of some web sites/applications. But we can at times forget how much web ...
15
You're confusing SSL/TLS with its most common usage pattern, which is TLS in conjunction with X.509 certificates and a Public Key Infrastructure (PKI, RFC 5280).
While it's really important to secure a TLS connection by authenticating its server site (to prevent active MITM attacks), the TLS specification doesn't actually mandate to do it using X.509 ...
15
This is a malicious request, but it's not trying to exploit a vulnerability. It's trying to generate a 404 page, in order to determine what kind of web server or CMS you're running, by identifying tokens in the page source. Error pages often specify their CMS name and version, or the web server name and version, so it's an easy target for recon.
Best advice ...
15
If you don't use HTTPS, but plain HTTP, then:
You will get hacked; credit card numbers will be stolen while in transit, and customers will sue you into oblivion.
You would be hacked anyway at some point, that's the lot of Web sites. Even if the hacker entered by some other way, post-mortem analysis will show the lack of SSL, and this will look real bad.
...
13
Your initial reaction is correct - this is a malicious request. The attack seems to be attempting to leverage an authentication bypass bug in a plugin, but I can't find which one. The attack seems to have been reasonably successful, since a large number of sites that show up on Google are now displaying pharma spam. I'd imagine the attacker is using a botnet ...
13
Your method is functionally equivalent to requiring authentication with two passwords, the Referer being one of them. A more common variant is to use a secret URL, i.e. to make the "special string" part of the path to the private site. Including the secret string in the URL may include some extra details to think about (e.g. users can bookmark it, meaning ...
12
As mentioned above, there are a number of HTTP proxies that allow intercepting and modifying requests and responses.
Here is a list of the ones I know about:
WebScarab (disclaimer: I wrote it)
Paros
Burp
ZAP (Z Attack Proxy - an updated version of Paros)
Fiddler/Fiddler2
Achilles
HTTPush
Exodus (disclaimer: I wrote it, and it is really old)
If you wish ...
12
I don't think that this kind of approach is a good idea. By using the sleep() function on certain requests you are making it easier for an attacker to create Denial of Service. He would just create a lot of request to the resource you are serving with a delay. This way, the number of requests the server can process at a time would be reached and legitimate ...
11
A while ago I used the Tamper Data Firefox Add-on and found it to be quite effective.
It has some good features like being able to choose what requests you wish to tamper with and also has some predefined exploits that you can use to populate field values with.
11
If I'm using websites that do not use HTTPS, but I'm on a WEP-protected Wi-Fi network, are my cookies safe from being sniffed by third-parties?
No. Outsiders can crack WEP networks almost as if they weren't encrypted at all, these days. Insiders have even more ease of access. Even on WPA/WPA2 networks, there are still exploits that enable insiders to ...
11
You cannot really hide the domain name, because if someone connects to the port 443 of your server and begins initiating a SSL connection, your server will respond by sending his certificate... which contains the server name.
Actually, the client may send the intended client name as part of a Server Name Indication, which is a rather recent extension which ...
11
When you send a request to the server, the server need to know where to answer, it's with your ip address. This is directly based on the TCP/IP protocol and in a lower slice than web servers.
For the reason why Firebug doesn't show your IP address, it's like when you receive mail (paper), you have your address written in front, and the sender in the back. ...
11
Certain elements of the page are not sent via HTTPS. This means that those elements can be read by anyone sniffing the network, or modified in-transit by an active attacker. This might result in an attacker executing JavaScript on the page. As such, your browser is warning you that the page is, for most intents and purposes, the equivalent of not being ...
11
HTTPS uses TLS, which is Transport Layer Security. HTTP as a protocol, runs above the transport layer. This means that all of the communication made by HTTPS, including the URL is protected.
Passing the session id in the URL is insecure for other reasons. For example it exposes the possibility of Session Fixation. The Session ID written to paper if a ...
10
Simple Proxy Servers
Even a simple proxy will see and log the names of the servers. For example visiting https://example.com/some/address.html will create a request like this from the browser to the proxy server:
CONNECT example.org:443 HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b13pre) ...
Proxy-Connection: keep-alive
Host: example.org
...
10
It's the same reason as why not all login prompts are using https yet: people are too lazy, think a certificate is too expensive, or have hosting that charges more for using https.
The real question is why downloads are served over a plain connection more often than login forms. And I think this is mostly because of unawareness. Checksums are often ...
Only top voted, non community-wiki answers of a minimum length are eligible
