US4 Include Classes

[mudmin]

Still working on it. I can't get the token to ever check as positive on my test even though it works perfectly all through UserSpice. Grr

[brian]

haha. are you sure about that? if you get a simple test form to work (whatever way you can) send it over so I can play with it and figure out how I can make it work in my situation.

[mudmin]

This is where I'm at on a test file called token.php in the users folder
http://hastebin.com/etebesufup.xml

You can see what the token is on the form and then you can see what is being submitted. I'm still getting a fail though.

[mudmin]

http://hastebin.com/uwujudaloc.xml

I did something stupid. The check needed to be above the form. Above is an example of my token.php file.

Also, if you're going to send info to a parser file and send it back
with ajax/jquery whatever, here's the order of operations.

1. Generate the token in the form.
2. Check the token in the parser file itself
3. Generate a new token in the parser file
4. Use Ajax/JQ to update the value of the hidden input in the form
with the new token value

[brian]

Yeah, see in this example, the token check occurs before the form, but since you are submitting the form to itself it results in a page reload since submission of the form itself calls token.php again.

I'll download this file to try it locally to get a feel for what the check success looks and feels like but I'm still not fully clear on how different your directions above are different from what I was doing.

[brian]

So I expected your example to work and it does of course, to maybe I'll try throwing a jquery parser into the mix on that same example and see what it throws back.

[mudmin]

I think the trick is that the token is allowed to change...it just needs to change when YOU detect input (then the users $_SESSION will be properly updated to match the token update. If someone hacks the page, they won't have the proper token in their $_SESSION and it won't work.

[brian]

Okay, it works. Lesson learned: any page that attempts to call US4 functions needs to require core/init.php . My token check worked fine, I just hadn't configured my page correctly. But now it's all good for what I need.

[brian]

well, it isn't really "hacks the page" so much as just forges the form. If they tried to forge the form they wouldn't have the right CSRF value, unless they already bugged the client system. In which case, they pwn it anyway.

Of course, a lot of this becomes moot if you're not using SSL to prevent external snooping. Even with the CSRF system in place, if you intercepted the form as it was being transmitted from server to client, they would have the required CSRF value straight from the traffic snoop, and could submit the form using the appropriate CSRF value as long as they did so before the client did.

Like on this word press page, all the login credentials get sent in the clear. Doesn't bother me though since I don't reuse passwords except in trivial pages.

[mudmin]

Well, and in a way you're a little bit safer using your parser file because you only check the token on a page that isn't externally available anyway. That's a minor bonus of doing things that way.

The other thing working in your favor is that (with the exception of sign up forms) pretty much everything is behind the login wall, so that limits the attack vector dramatically. It's not like some outside bot would normally get by that.

Another honeypot type thing people do is hide inputs on the form (like do a random hidden text input on the form) and if it comes back with text on it, kill the page because it means it was filled out by a bot. The bot often doesn't really have a way of knowing that the input was hidden to begin with. That's the gist of how most forum spam preventions work from what I understand.