Tag Info

Hot answers tagged

9

You can try StartSSL who will issue you a free SSL certificate that will be trusted. I use one of their certificates on my blog and yes, it really is free. Their site doesn't have the best user interface admittedly, but if you can live with that, this sounds like your best option.


8

Yes, and this is exactly what the SSL Strip attack did, while using the unsecure HTTP connection it transparently turned all HTTPS links in to HTTP links and proxied the connection, if you did not notice that you where not on a HTTPS connection you could easily send confidential data over a unsecure connection. As a web site admin you can combat this by ...


4

The number one reason why we are not all compromised is that there are just not enough attackers to do the job, and most of you are not interesting enough targets either. Civilization as a whole can keep on running because most people are basically honest; you can walk in the street among complete strangers and none of them will try to punch you or stab you, ...


4

Especially on a login page the entire page should be https. Making, of all pages, the login page http and putting the https under a button is bad practice in my book. This makes it a lot easier to perform MiTM/SSL strip attacks by replacing the https action under the button with a simple http link and no one can tell unless they inspect the source (as ...


3

There is a standard for STARTTLS in plain HTTP. Note that "STARTTLS" is still SSL; it merely modifies the dynamics, but no implementation complexity is avoided that way. Generally speaking, nobody uses STARTTLS for HTTP, mostly because it is less secure. Indeed, a very big part of SSL-for-Web-browsers is the visual feedback, by which the user is made aware ...


2

Not all links are restricted to your initial request; if you include the protocol (e.g: http or https), then you can jump between both. If you just have relative URL locations (such as: "/dir/page.php" instead of "https://site.com/dir/page.php"), then you'll stick to the same protocol. Websites can implement Hypertext Strict Transport Security, this will ...


2

I think I know what's happening with you. Actually, that's exactly what I do with the image in my "about me" section in my StackExchange profiles. It's a .php file that grabs some information about the visitor (IP address, browser type, whether the visitor made the smiley happy or not, etc.*). I simply rewrote the URL to show two different images that are in ...


2

Train users to always type https:// for your site, or get the browser makers to hardcode your site in the preloaded HSTS only. Really not much else you can do. EDIT: Also apparently turning off port 80 (besides simple redirect to https) would work to stop SSL Strip; granted it should be possible to go beyond SSLStrip to do a MitM attack against a site that ...


2

I think RFC 2616 is quite clear: 10.4.4 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the ...


1

View the page HTML source and locate the form tag. Look for the action and method. e.g. on www.facebook.com the source shows <form id="login_form" action="https://www.facebook.com/login.php?login_attempt=1" method="post" Here you can see that it is a https form and that the method is POST. If there is no action then the default is GET. How these ...


1

Actually most Web sites do implement forward secrecy, i.e. at least one of the "DHE" (or "ECDHE") cipher suites. Most SSL implementations support them out of the box, and most SSL server certificates are adequate (with a DHE cipher suite, the server's key is used for a signature; but almost everybody uses RSA and almost all RSA certificates allow the key ...


1

DHE handshake is very expensive and thus might heavily impact the performance of the server. ECDHE is much better (only about 15% overhead with optimized implementations) but you need a library which supports it. OpenSSL, e.g. the library which is behind most of the UNIX based webservers, added support with 1.0.1 - and yes, this is exactly the version which ...


1

The request and response the reports show are not so much for detecting (since it already detected it) its more for solving it. By looking at the request you can see in what URI and what parameter the tool injected the script and by looking at the response, you can see where the injected script was reflected. With this information, you can now go to your ...


1

Current browsers support SNI (server name indication), which sends the name of the target host inside the initial client hello. Thus it is possible to have different https servers on the same IP and current http servers support this. There are still problems with non-browsers (tools and SSL libraries or SSL interfaces in various languages). Some do use SNI ...


1

If you take a look at the form posting your login details you will see the following: action="https://corsair.secure.force.com/SiteLogin?refURL=http%3A%2F%2Fcorsair.force.com%2F This action is in fact posted over SSL/TLS. In an ideal world, the whole site is SSL. Currently, for the site in question, the login details are posted over a secure channel. ...


1

If you're worried about security you could use the naxsi module with nginx and catch such attempts a bit more explicitely with rules. I'm pretty happy with it - it's fast and lightweight. https://github.com/nbs-system/naxsi


1

Thomas has already written an excellent answer, but I thought I'd offer a couple more reasons why HTTPS is not more widely used... Not needed. As Jesper's answer insightfully points out "the majority of information on the web doesn't need security". However, with the growing amount of tracking taking place by search engines, ad companies, country-level ...


1

Preventing cross-domain WebSockets is server-sided. So yes, a successful XSS attack can create a websocket connection to a 3rd party server and send sensitive information. But it's far from the only technique an XSS attack can use to leak information to a 3rd party server. Take the following code for example: var password = getCredentials().password; var ...


1

Generally speaking, login pages don't display content that can be attacked with XSS. There isn't a good way to alter the code on that page to be able to monitor the entry. Also, in general, XSS protection is pretty good on most modern sites, at least on the parts where it could be particularly damaging.


1

You need a wildcard certificate with alternate name support. I use one from StartSSL. You have to get a class 2 certificate, so it does have a small cost ($60 for a year of issuing unlimited number of 2 year long certificates) but you can then create a certificate which will cover all sub-domains and domains on your site. It needs to all be on one ...


1

Yes - Security certificates are tied to a domain (even example.com and www.example.com would technically need two certificates or a multiple domain certificate). You can get a wildcard certificate, but I think they are still very expensive and work for one second-level domain. Yes - I think you should be OK submitting across domains since you (presumably) ...


1

It seems that using SSL after the password is entered is pointless, as an attacker can already intercept the connection and get the login details. No, the credentials itself would usually be transferred securely. Before your browser sends anything out a SSL/TLS connection is established, which is then used for the actual application data. Note however, ...



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