Injection vuln. in WebLogin

I’m not sure if this is the right subforum for this, please move if necessary.

I stumbled upon an injection problem in the WebLogin snippet after making a typo. It seems that if you enter "> into the username field, anything after it gets rendered. See my screenshots below.

This is a bone stock installation of ModX 0.9.5. I’ve also verified this on a few live ModX sites.

I entered

in the username field.


It kicked back the popup for incorrect username/password, but still rendered the bolded XSS.


I’ve also successfully injected images. I haven’t been able to get a script to run yet, but I’m sure its possible with some mucking about.

I’m not a big security person, but I think this can cause some problems.

I’ve looked through the snippet code, but can’t seem to figure out where this is happening. Can anyone fix this?

Hmmm, I can’t reproduce this on any 0.9.5 sites I have. Can you try out the 0.9.6 RC1? I know this issue has been globally addressed since the 0.9.5 release, but the escaping in the 0.9.5 version should be handling this. Is it possible you have an old version of the weblogin code? Otherwise, you can alter the weblogin script to escape the username (and password) as well as strip any tags from it specifically...

I’ve recreated this on a couple sites I found here in the Forums:
http://www.oracleunittesting.com/
http://www.scottydelicious.com/
Not sure if that helps any.

Edit -- I also just tried a stock install on a completely different server, same problem.

I also just did a fresh install of 9.6 RC1 and recreated the problem.

Both times were the default weblogin code from the package, so I assume I’m using the most recent login code. Is there an update for it?

Also, how would I go about escaping the username and strip the tags? I’m pretty new at PHP.

Where is the code currently that sanitizes the input? Is it the stuff in the beginning of index.php about securing variables from the outside? I want to learn more about this but don’t really know where to start.

This is simply a problem with rendering in your template; the data is escaped before it is sent to through the database query. You can fix the rendering issue by finding the line in /assets/snippets/weblogin/weblogin.inc.php that says:



and changing it to



Hope that helps you...

Thank you for your help so far.

Unfortunately, the new line in weblogin.inc.php didn’t solve it.
I’ve also noticed that neither the password input nor the email address for forgotten password input is having this problem, just the input for username. That makes this even more confusing to me, since their posting to the same place.

If you’d like I can email you the link to the page if you want to see the bug in action and don’t want to use the other sites I linked previously without permission.

EDIT -- I just noticed that now, after submitting, the XSS " /> is still showing up below the username filed, like in the above screenshot, only now, instead of the username field being empty, it has a single backslash in it. If I press submit again, it has 2, then 4, then 8 etc. Does that help at all?

Bump because I haven’t figure out how to fix this yet, and I know other people have this problem.

Add strip_tags() as is now done in the latest SVN trunk...



This will prevent the HTML injection from making it back to the login form.

You might also want to replace double and single quotes in that input just to not break the HTML output if some schmuck enters them.

As an aside, is this technically considered an "injection" vulnerability? You could certainly include and execute javascript or a binary (Flash, image, etc.) file, but I don’t see how you could include a file to be executed server-side. You’re not breaking and entering until after the HTML is rendered, so that seems like a slightly different (and perhaps lesser) threat.

It’s tempting to stop the actual work I’m doing to try to figure out a JavaScript that could really take advantage of this, but I’ll resist the urge...

strip_tags is not very secure if you are really in need of, maybe adding a more powerful code cleaner would be better.
Something like inputfilter.

As for the weblogin issue (i’m not sure if it is), what could be the big problem here with XSS as it won’t match an existing username and log somebody in with that code?

Quote from: Boby at Mar 20, 2007, 01:08 PM

strip_tags is not very secure if you are really in need of, maybe adding a more powerful code cleaner would be better.
Something like inputfilter.

As for the weblogin issue (i’m not sure if it is), what could be the big problem here with XSS as it won’t match an existing username and log somebody in with that code?

The critical stuff is already stripped on every MODx request...this is just to prevent any leftover HTML tag stuff from messing up the presentation when they attempt these XSS attacks...