The source code interpreted by the browser, have html comment with the subject by each comment. For example, if we post a comment like 'Hello', Drupal write in the source code

. But the problem come when a post is send with special characters like '<'. The subject string is not analized to find and replacing special characters that could do a XSS Attack. If the comment posted is similary to '-->Hello XSS', the comment in the source code will be closed, provocating that "Hello XSS-->" string will be show in the page. If the "Hello XSS" string will be replaced by a script, we can get a XSS Attack.

Solution
Analize the subject string and replacing the special characters (<, >, ') for (<, >, ")

How
Adding this lines to the function comment_validate_form:
$edit['subject'] = ereg_replace("<", "<", $edit['subject']);
$edit['subject'] = ereg_replace(">", ">", $edit['subject']);
$edit['subject'] = ereg_replace("\'", """, $edit['subject']);

Notes
- Sorry, but my english is not very cool.

CommentFileSizeAuthor
#2 comment.module_27.patch1.04 KBThox
comment.module_13.diff632 bytesMogurito

Comments

Mogurito’s picture

Mogurito commented

CORRECTION (The comment is not complete)

The source code interpreted by the browser, have html comment with the subject by each comment. For example, if we post a comment like 'Hello', Drupal write in the source code . But the problem come when a post is send with special characters like '<'. If we post a comment like '-->Hello XSS', the comment in the source code will be closed, provocating that "Hello XSS-->" string will be show in the page. If the "Hello XSS" string will be replaced by a script, we can get a XSS Attack.

Solution
Analize the subject string and replacing the special characters (<,>, ') for (&<, &>, &")

How
Adding this lines to the function comment_validate_form:
$edit['subject'] = ereg_replace("<", "&<", $edit['subject']);
$edit['subject'] = ereg_replace(">", "&>", $edit['subject']);
$edit['subject'] = ereg_replace(""", "&"", $edit['subject']);

Notes
- Sorry, but my english is not very cool.

Thox’s picture

Thox commented
Version: 4.6.0 » x.y.z
StatusFileSize
new comment.module_27.patch1.04 KB

I imagine it is wiser to handle this with check_plain() in theme_comment(), the same as it is handled in theme_node(). See attached patch against CVS HEAD.

tostinni’s picture

tostinni commented

Can you give us a proof of concept, because, I can't reproduce it.
If I put something between a <script> tag, it is stripped out.

In fact everything rely on the action of filter module, which take care of stripping undesirable code. And I think that it's doing a good job.

Mogurito’s picture

Mogurito commented

Yes, see this link. I posted a comment with a subject that containt a script. See the comment.

eldarin’s picture

eldarin commented

Quite serious implications ...
This would of course allow someone to pick up all the user passwords being typed on pages !!!
The worst one of these is of course the admin user and password. It's very easy to get some DOM-handling and attaching to the submit of the user login form.

8^O

morbus iff’s picture

morbus iff
they/them
commented

Mogurito: what are your input filters configured as, and what version of Drupal are you running? My two concerns are: you don't appear to be running the default Drupal comment input filter (which restricts allowed tags to A B I EM STRONG UL OL LI - see also my H1 test on that comment). Can you duplicate this behavior on a new install of Drupal 4.6.3? I am unable to duplicate this using today's HEAD, with the default "Filtered HTML" input format (in fact, I get "Terminated request because of suspicious input data." If I switch this over to the "Full HTML" input format, which supports, uh, Full HTML (and every nastiness that entails), then it DOES work.

moshe weitzman’s picture

moshe weitzman commented

@All - please stop posting here immediately. Security issues are discussed on the drupal-security mailing list.

Mogurito - please reply to the questions asked here using the 'security issue' category at http://drupal.org/contact. As of now, we have no evidence that this is a real vulnerability, and not a misconfiguration. Having said that, we take these reports very seriously.

eldarin’s picture

eldarin commented

Yes, hehe ...
I tested it as well, and found no such vulnerability. I think it looks like a false alarm too.
*phew* ;-)

morbus iff’s picture

morbus iff
they/them
commented

Can you do me a favor: log out and try to replicate this as anonymous? I suspect this is what is happening:

  • You are currently logged in as the root (first) Drupal user.
  • The root user is exempt from "bypass input data check".
  • You, as the root (first) Drupal user, can post your XSS test.

But, if you log out, and as the anonymous user, try to add your XSS test, you should see the same "Terminated" message I pasted before - in fact, I can go to your site right now and confirm this - as an anonymous user, I can not add the XSS test because I get the above message.

tostinni’s picture

tostinni commented

@moshe moshe weitzman :
I don't remember having seen the security mailing list here, can you point me to it ?
I think that the discussion worth take place here because Mogurito started it there, so maybe the place was not good enough at the beginning, but splitting it to a mailing list maybe disturbing don't you think ?

@Morbus
Even connected with user 1, I can't reproduce this.

chx’s picture

chx commented
Status: Needs review » Closed (won't fix)

As noone is able to reproduce what's there to fix?