Does https connection secure cookies and prevents XSS attacks. I have a simple blog that allows users to enter JavaScript code as an input. I want to allow Javascript input by the user while still preventing XSS attacks and cookie stealing. Does https help secure cookies. I only found few sites that talks about this and still a bit unclear.
-
HTTPS in itself doesn't prevent XSS. – Steven Jun 30 '11 at 05:34
-
1Allowing users to input Javascript is **extremely** dangerous. It is very difficult to prevent a malicious user doing some very nasty things to your other users. – Cameron Skinner Jun 30 '11 at 05:57
-
@Cameron - whether it is dangerous or not is irrelevant. Given that browsers support the *javascript* pseudo–protocol and add-ons like Greasemonkey and Firebug let users run scripts in pages, it is impossible to stop users from running whatever script they want in the pages in their browser or any other user agent. – RobG Jun 30 '11 at 06:55
-
@Keoki - I think the question is how to write safe code. As a developer, i would search here in stackoverflow. – martinstoeckli Jun 30 '11 at 08:14
-
@RobG: The point was that if I allow user A to entry arbitrary javascript and my server serves it to user B then that is a great avenue of attack for malicious user A. The point is not that any one user is running Javascript; it's the potential for users to cause problems for each other that's the trouble. – Cameron Skinner Jun 30 '11 at 23:01
5 Answers
HTTPS can prevent a man-in-the-middle attack, not XSS. Unfortunately the session cookie is not secure with this alone, one can request a page with HTTP and then the same cookie will be sent unprotected.
To ensure that the session cookie is sent only on HTTPS connections, you can use the function session_set_cookie_params() before starting the session:
session_set_cookie_params(0, '/', '', true, true);
session_start();
Note the first true
, it means that the cookie will be sent only to HTTPS pages. The second true
tells the browser, that JavaScript must not access the session cookie, it depends on the browser if that is done correctly.
Another good way to make your site safer is, to use the session cookie only for maintaining the session, and using a second cookie to take care of the authentication. I can provide an example if you are interested.

- 23,430
- 6
- 56
- 87
-
Yes definitely, show an example. According to your answer, if session cookie is forced to go thru https connection, then can we say it is safe from xss attacks. – Hussein Jun 30 '11 at 08:24
-
@Hussein - The session cookie is not part of an XSS attack, a good explanation about XSS you can find here: http://shiflett.org/articles/cross-site-scripting . The example i have written describes how to use mixed HTTP and HTTPS pages, but it shows also how to keep session and authentication separate http://www.martinstoeckli.ch/php/php.html#ssl_nomim_cookie . The session cookie will always be the target of attacks. – martinstoeckli Jun 30 '11 at 08:33
The HTTP protocol (HTTPS or HTTP) does not help with XSS or really have any relation. You'll need to add preventative measures and be careful where you output the javascript to the client.

- 51,692
- 2
- 65
- 86

- 2,471
- 15
- 24
-
@comm @cwa @jake thanks. Let's say we want the user to input Google ads code in the blog. Google code is javascript. We can't strip javascript out since it is needed. If we allow javascript then we are open to many areas of xss attack. What is the solution to this. I'm sure there's a way to go about this. – Hussein Jun 30 '11 at 07:09
Once you've allowed someone to dynamically store and execute arbitrary JavaScript on your site, they have access to a lot of stuff you would want them to leave alone. At a minimum, they can hijack your PHP Session ID (they'll have access to your cookies, after all) and then use Ajax to forward it to some remote server. Once they have that, they can then do all sorts of crap to your users.
If you have to let them add their own JavaScript, I would recommend that you specifically disable all Ajax functionality (XMLHTTPRequest = function(){}
prevents all Ajax pretty easily on most browsers, but you might need to look into what IE needs (I don't know what ActiveXObject = function(){}
will do...)). Unfortunately, you can't prevent access to cookies if you have any expectation of using them (i.e. if you have a session), so you will need to find some other workaround.

- 79,954
- 26
- 128
- 166
If you want users to be able to input JavaScript code, but not have it parsed, run it through htmlspecialchars. If you want them to be able to execute code, then no, HTTPS won't help, and you're going to need to parse the code and remove anything bad from it.

- 597
- 2
- 10
- 22
You can use a Web Application Firewall to scan and block XSS, including in cookies though the latter can cause false positives https://medium.com/p/5d4b1d33219a/edit

- 1,350
- 1
- 16
- 36