Search the Community
Showing results for tags 'CSRF'.
Found 7 results
-
I am implementing the ability to handle form submission using AJAX. The problem I have is that even though, as far as I can tell, I convert the AJAX-submitted JSON input into the equivalent of $input->post. When I call $form->processInput() it always throws that it appears to be forged. if ($config->ajax && $_SERVER['REQUEST_METHOD'] === 'POST') { // get the file body and decode the JSON. try { $body = file_get_contents('php://input'); $json = wireDecodeJSON($body); //wire('log')->save('info', 'ajax-json:' . print_r($json, true)); wire('log')->save('info', 'json-data:' . print_r($json['data'], true) . ' sid: ' . session_id()); $fakeinput = new WireInputData($json['data']); $form = deleteRequest('xyzzy'); $form->processInput($fakeinput); } catch (Exception $e) { http_response_code(404); echo json_encode(array('reason' => $e->getMessage())); } return; The log shows that the TOKEN and the TOKEN value are the same as when a normal form is submitted (I have both on the page for testing and can submit via normal POST as well as via AJAX). The session_id() value is the same. What am I missing? Log entries ("dumb" is the normal submit button name, "fake-text" is an empty text field, "submit" is the AJAX submit button name.) (using form-post): post Array ( [dumb] => dumb-button [TOKEN1649939534X1479234443] => f4VLZ17RlXfp9KVCQr/GIhoZ3krbuWK5 ) (using ajax-post): json-data: Array ( [fake-text] => [submit] => DELETE ENDUSERS [TOKEN1649939534X1479234443] => f4VLZ17RlXfp9KVCQr/GIhoZ3krbuWK5 )
-
Hey, I've been trying to implement some progressive enhancements to take advantage of modern browsers, modern JS and CSS capabilities etc. One thing I've got stuck is to CSRF protection using $session->CSRF. I'm echoing hidden token using <?= session()->CSRF->renderInput('contact') ?> inside the form, and I can validate the token with plain POST request (without AJAX) just fine using session()->CSRF->hasValidToken('contact'). For AJAX, I'm setting headers x-<tokenname>:<tokenvalue>. It shows up in both Chrome DevTools correctly, and on backend lke HTTP_X_<TOKENNAME> => <TOKEN_VALUE> as expected, so there's no miscommunication. But, when I try to validate it, it fails no matter what. After some debugging I realized at each request, a new token is created, which invalidates the one I'm sending. Here are the relevant parts from the core. Inside /wire/core/SessionCSRF.php, where validation occurs <?php public function hasValidToken($id = '') { $tokenName = $this->getTokenName($id); $tokenValue = $this->getTokenValue($id); // ... if($this->config->ajax && isset($_SERVER["HTTP_X_$tokenName"]) && $_SERVER["HTTP_X_$tokenName"] === $tokenValue) return true; if($this->input->post($tokenName) === $tokenValue) return true; // if this point is reached, token was invalid return false; } it gets token name from here where it checks inside $_SESSION variable <?php public function getTokenName($id = '') { $tokenName = $this->session->get($this, "name$id"); // Why can't it find token inside $_SESSION global? if(!$tokenName) { $tokenName = 'TOKEN' . mt_rand() . "X" . time(); // token name always ends with timestamp $this->session->set($this, "name$id", $tokenName); } return $tokenName; } I dont understand why it cannot find correct token and regenerates? Does session not last until browser closes? I can save other data to $session, and get it just fine, am I missing something?
-
Hi, I'd like to add some CSRF protection on my sign -up form. I've successfully applied that method : https://processwire.com/talk/topic/3779-use-csrf-in-your-own-forms/ (generate the tokens and once the form is posted, check the tokens with $session->CSRF->validate(); ) I've read stuff about $config->protectCSRF; but I don't understand : - it's ON by default but what does it mean ? Are my forms protected by default or do I have to add the above stuff ? - (bonus question) how do you hack your own form to simulate an "attack" ? I've tried chrome debug console but did not succeed to edit the token I've generated in the sign-up form Thanks !
-
I'm having a strange problem with CSRF, hasValidToken() only works on internal pages and not on the homepage. The weird thing: is the same form, I have a modal in the footer, so every single page uses the same form. If I register using an internal page it works fine, if I use the homepage to register, the csrf token returns error. This is what I use to validate: if ( ! $this->session->CSRF->hasValidToken() ) { $errors['csrf'] = __( "Form submit was not valid, please try again." ); } Any ideas?
-
Hi all I have built my own module for processing forms on my site. The module does check to see of the request was forged or not, but I am unable to inset the token name and value into my template. I use Twig for my templates, and this is what I'm calling: <form data-form-ident="contact-form" data-form-token-name="{{ this.session.CSRF.getTokenName() }}" data-form-token-value="{{ this.session.CSRF.getTokenValue() }}"> The output for that is an empty string. Could it perhaps be because I am using Twig? Side note: disabling Twig is not an option as the templates I'm using are very complex - it would be a darn mission to revert to native PHP. (PW 2.4.0)
-
I am stuck. Seven days ago, something changed such that when users try to upload images to my PW site, the images are posted to the page, but they show up as zero bytes. The folder is created in the files folder, the image name is recorded, the type of file is recorded, but the byte size is zero. When I looked into the problem this morning, I received the "This request was aborted because it appears to be forged." message whenever I tried to upload images. Turning off protectCSRF in the config file suppresses the aborted image message and now I just get the zero-byte image bug, but I don't know why. I've checked permissions on the files directory, changed it recursively to 777 and then back to 755 with no change. I checked that I have active sessions, logs, and cache folders. I checked on the permissions of the config.php file. I changed the sessionName, and turned off the challenge and fingerprint functions but nothing is budging. I installed a new PW site yesterday and so I keep thinking something is colliding but it looks like the images have been failing to write to the files directory for the last week. I'm getting the same results in multiple browsers after any number of cache-clears so I don't think it is client-side. This is a look at the PHPinfo for the site. Best wishes, J
-
Some interesting reads for those interested in security: Well it should be mandatory for every webdev to know these thing or at least care about. Hack yourself first - how to go on the offence before online attackers do http://www.troyhunt.com/2013/05/hack-yourself-first-how-to-go-on.html Feel free to discuss or post other articles about the subject.
