+- UserSpice (https://userspice.com/forums)
+-- Forum: Support Center (https://userspice.com/forums/forumdisplay.php?fid=23)
+--- Forum: UserSpice 4.3 and Below (https://userspice.com/forums/forumdisplay.php?fid=26)
+--- Thread: US4 Include Classes (/showthread.php?tid=88)
US4 Include Classes - brian - 02-24-2016
I have a php script handler for some jQuery code, and the script handler at the moment is just a plain old file with minimal php for processing. How would I go about including the Userspice classes, aside from require_once a bunch of times in my own form of header file?
US4 Include Classes - brian - 02-24-2016
To extend on what I'm trying to do: I'm trying to make use of the Token class in the following way.
I have a function which generates the submission form. In that form I use the Token::generate() function to generate the token, and that is inserted in the form (the Token::generate function call is immediately before the form function call with the token as an argument.
The form is submitted through a jQuery call and the form data is $_POST'd including the token. Then in the form handler php script, I run the Token::check function and it always returns that the tokens don't match.
I'm trying to figure out what I'm doing wrong. What I don't understand is how the generation and the check are synchronized.
US4 Include Classes - mudmin - 02-24-2016
On the first question, if you include the init, that auto includes all the classes and makes them work right.
The token thing...that's tricky. Every time there is a new session a new token is generated to prevent the CSRF attacks. I think the trick is to check the token while you're still on the existing page, and THEN send them to your parser file (that other file with the php/jquery in it).
So, regardless of where the rest of your form processing happens, do the token check on the page with the form itself. The whole point is that the input was from the same session you displayed the page on. After that, the data is all server side, so there's really no place for a cross site or man in the middle attack on it.
US4 Include Classes - brian - 02-25-2016
I guess I assumed the "session" was more persistent than the page. In this case, the jQuery passes the post data (including the CSRF) to the parsing PHP (which doesn't have any of your session management code, only includes for the Classes which I just did manually which is probably wrong.)
And when you say "include the init" you are talking about core/init.php?
US4 Include Classes - brian - 02-25-2016
So in all the cases you are using the CSRF, how is the processing being done? I assume you are using $_PHPSELF to process with the same page? My whole point of using jQuery is to avoid refreshes and the user losing their spot in the page. I guess I'll have to think about this some more.
US4 Include Classes - mudmin - 02-25-2016
The token is regenerated every time the page loads/refreshes.
I don't have a problem with loading classes manually. I do it all the time when I need to. The reason I suggested the core/init.php file is because that's where the database connection info, the cookie info, and the token info are stored. Plus it autoloads the classes to boot.... That might actually be the bulk of your problem.
The way it works (if I remember correctly is:
1. core/init.php defines the core information needed (connections, cookies, etc) and then autoloads the classes.
2. The config class parses all this stuff into a format the other classes can use.
3. The other classes do their thing.
So, about the token. It can be checked at any point during the process, it just needs to know where to look for the token. The default area is $_POST['csrf']
I do this check somewhere at the top of any time I post user input
Code:
$token = $_POST['csrf'];Code:
if(!Token::check($token)){Code:
die('Token doesn\'t match!');Code:
}else {Code:
//The rest of my code including jQ and AJAX.I wrote some code for the join.php file that I wound up pulling out. Let me go back to github and see if I can find what I did to use the token during an AJAX call which should be similar.
One more note. You can always echo out the token at all times to see what the system thinks it is.
Instead of doing something like
Code:
<input type="hidden" name="csrf" value="<?=Token::generate();?>" >Code:
$csrf = Token::generate();Code:
bold($csrf); //Just echoes out your token in a bold font with a white backgroundThen on the form you just do
Code:
<input type="hidden" name="csrf" value="<?=$csrf?>" >Then, to see what's going on, you can do something like
Code:
$token = $_POST['csrf'];Code:
bold($token);Code:
if(!Token::check($token)){Code:
die('Token doesn\'t match!');Code:
}else {Code:
//die('Token matches');Something like that. Anyway, the point is that the token doesn't need to be a secret to you.
US4 Include Classes - brian - 02-25-2016
Yeah, I've done a bit of that (dumping out the token to see what it is). Is there a trick to finding out what the token "verifier" is expecting? I'll try including the Init file and see if that does anything for me. I'm working on some other jQuery stuff right now so we'll see how that goes.
US4 Include Classes - mudmin - 02-25-2016
I'm writing a test file now to check it. Stay tuned.
US4 Include Classes - brian - 02-25-2016
Tuned.
US4 Include Classes - mudmin - 02-25-2016
The problem is that checking he token deletes it from the session. The check function has this line in it...
Session::delete($tokenName);
That's supposed to prevent it from being reused. I'm checking if it it secure to do an ajax check function or something like that which doesn't delete it. I feel like that's a security vulnerability, but I'm checking.