Tag Info

New answers tagged

0

Is there any way we can avoid it? Yes, you could have a rolling session key. i.e. the server will generate a new Session ID to store in the cookie every n number of requests. The Set-Cookie header will only be sent once, so if there are two browsers logged into the same session, one of them will be using the old, invalid session. You could have a small ...


0

Cookies have an option to force encryption. Simply add secure; to the cookie header: Set-Cookie: mycookie=somevalue; path=/securesite/; Expires=12/12/2010; secure; httpOnly; httpOnly; protectes the cookie from JavaScript. See How can I check that my cookies are only sent over encrypted https and not http? Also keep in mind that users IP might change ...


2

If the certificate is there, then chances are that it is used for something, and that something will probably break when the certificate expires. In your case, if you use pure NTLM, then it seems that no certificate is used at all, so maybe you can let the certificate die and see that nothing happens. However, authentication in SharePoint can be complex so ...


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


3

Train users to either always type https:// for your site, follow links from a site like google (that has hard-coded HSTS), or use a bookmark. (Do this training in addition to other sensible training policies: do not do security sensitive things on unsecured/public wifi or public computers, use strong passwords that aren't reused, etc.. Then try getting ...


0

The only way is to not offer any sensible data (this includes login forms already) on port 80. This way the client must switch to https, either by hand or automatically through redirection etc.


0

When I had this problem, all I did was add a couple of entries to my IP tables. If you are running linux, then this is really simple. Run this command for each of the offending ip addresses: iptables -A INPUT -s IP-ADDRESS -j DROP http://www.cyberciti.biz/faq/how-do-i-block-an-ip-on-my-linux-server/ This will make sure all packets that come from those ...


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

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

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


0

Not only should you implement HTTPS, but it should be on by default. This reminds me of a quote from the EFF that went something like this: "in an ideal world, every web request would be sent over SSL/TLS." Security and Privacy should be on by default. It cannot be optional. And for privacy to not be suspicious, everybody needs to do their part. Like others ...


0

There is a 'free' SSL initiative called CA Cert. Unfortunately not many (popular) OS's or browsers come with it's root CA installed per default, but it is easy to install for your end-users. See here for more info: http://wiki.cacert.org/InclusionStatus Depending on your needs you must be 'assured' by some other members of CA Cert. Please look here for ...


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


-1

if someone is able to change the htaccess - entries on your server you're probably hacked. the png might contain malicious code; can you paste the output of $ string strangefile.png when executed on the server? might be interesting What's the worst they can do with .htaccess masking? Any way to prevent it? they have access to your server, it is ...


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


0

Web-Proxy Um, trying to look into my crystal ball here. Web proxies in general cannot cache SSL connection content, must pass the traffic through unaltered, and cannot view the content as it passes through. Is this bad for the following reasons? High traffic on your site because of lack of caching (may be able to alleviate with tuning cache settings, ...


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


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


0

I think you misunderstood STARTTLS. This command just tells the other server, that the clients wants to do TLS and after the server agreed the normal TLS handshake will start, e.g. with certificates and all the stuff - same as with https. The main difference is, that you don't commit to TLS right after TCP connect, but only after exchanging some plain text ...


0

You shouldn't. The reason being, the https:// URI scheme signals both to the user and to the browser that it is acting in a secure environment, and precautions should be taken to prevent secure information from leaking to an insecure environment. This is well-understood and a pretty strong system. The mechanism a server would use for switching from an ...


0

An easy way to do an SSL-strip attack is, when you offer a WLAN access point at a place where already a public access point exists (Moxie Marlinspike did this to demonstrate SSL-strip). As soon as somebody connects via your access point and visits a website with the HTTP protocol, you can read everything he sends and return everything your want. If the first ...


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


0

Well yes seen as your now browsing the internet with cleartext requests and responses but only would prove a big issue with accounts as you mention. It wouldn't be an issue if your were browsing google per se. Moxie Marlinspike has done a lot of research into the SSL/TLS protocols and created a tool called sslstrip:here!. Thus the only threat is the attacker ...


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


0

You might want to read up on IDN homograph attacks or script spoofing. Since characters outside of the usual a–z (case insensitive), 0‒9, and - (hyphen-minus) can now be used, the possibilities have greatly expanded. Whereas previously, you could only hope to trick users by using combinations like vv to substitute for w, now any Unicode homographs can be ...


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.


0

no, it's not possible for free because the trust-chain can't be established. Your visitors may have access to some CA's by default, because those CA's have made investments to establish themselves as root CA's in the most common browsers/operating systems (or made it) etc. Without there being a free one you can't establish a free trust-chain, so a visitor ...


0

Sorry, but what you're asking for isn't possible. You can only have two out of three: Free as in beer, zero hassle, or security. It is possible to not pay for a certificate and have a no-hassle solution, but the drawback is obvious. Of course you can also pay up for a certificate, and users can easily use our website/service, but you'd be out a few beers. ...


0

There aren't a lot of options here once self signed certs are out of the mix. But check out cacert.org I've heard (some) positive things about it. It's mission seems to fit your use case, it's certainly not a high quality, high trust cert, but it may well meet your needs.


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


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


0

An attacker really doesn't need access to the "Internet line" to redirect someone to a fake web page. If an attacker has access to the sever he/she would be able to do some cloning and change the I.P address of to whatever he would like - but you could use "phishing" technique to redirect to another url. Computer are only as smart as the user - so while a ...


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


0

The security of the web hinges on trust. You trust users to use a secure browser. You trust the browser to prevent cross-domain requests unless explicitly permitted (this seems like you're main concern). You trust your Twitter, Facebook, and jQuery libraries not to be doing anything nefarious. And as the user, you presumably trust only certain dot-coms to ...


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.



Top 50 recent answers are included