So for a while now I've been experimenting with different AJAX approaches in sending data to a server that will be processed and stored inside a MySQL database.
The page that the AJAX request hits api.php
, uses PHP's PDO prepared statements to save the data, so MySQL injections aren't really a problem and the passwords or data that needs to be encrypted are also handled by api.php
which isn't what I'm asking here. My question relates more to how to ensure the data is secure when being transferred from the client to the server.
I currently have (for the login example I have included below):
login.php
and api.php
in this example).api.php
when accessing functions.api.php
.api.php
(not relevant to the question).Finally, my questions are:
I understand everyone has different approaches to handling their site's data and transporting that data. I also understand that no matter what you do, you can never be 100% protected, as there may be vulnerabilities and ways around your system that you can't account for. I'm looking for feedback/improvements on my general approach in sending data securely rather than criticism of the specific code below as it is only an example. But any constructive answers are welcome. Thanks for taking the time to read/answer.
function loginUser() { var process = "loginUser"; var data = $("form").serializeArray(); data[1].value = SHA512(data[1].value); // sha then encrypt on api.php page data = JSON.stringify(data); $("#loginButton").html('<i class="fa fa-spinner fa-pulse fa-lg fa-fw"></i> Login'); $.ajax({ type: "POST", url: "api.php", data: {"process": process, "data": data}, success: function(data) { if (data.response.state == "success") { // if api.php returns success, redirect to homepage } else { // if api.php returns failure, display error } }, error: function(jqXHR, textStatus, errorThrown, data) { // error handling }, dataType: "json" }); }
AJAX calls are itself protect CSRF using “Common Origin Policy” when CORS is disabled and JSONP requests are blocked. To prevent CSRF attack one step ahead, we can implement Anti Forgery token similar to MVC framework. AJAX calls can be called from web application as well as from MVC. In MVC, @html.
jQuery provides several methods for AJAX functionality. With the jQuery AJAX methods, you can request text, HTML, XML, or JSON from a remote server using both HTTP Get and HTTP Post - And you can load the external data directly into the selected HTML elements of your web page!
Start Using AJAX Today In our PHP tutorial, we will demonstrate how AJAX can update parts of a web page, without reloading the whole page. The server script will be written in PHP. If you want to learn more about AJAX, visit our AJAX tutorial.
If someone has complete access to a browser, then they can run any code they like in it - including modifying or adding JavaScript to your pages. That has absolutely nothing to do with a site using Ajax though — any point where the client interacts with the server may be vulnerable.
1. Check the ORIGIN header
As specified by OWASP, this is not enough but recommended :
Although it is trivial to spoof any header from your own browser, it is generally impossible to do so in a CSRF attack, except via an XSS vulnerability. That's why checking headers is a reasonable first step in your CSRF defense, but since they aren't always present, its generally not considered a sufficient defense on its own.
And by Mozilla :
The Origin header is considered helpful against JSON data theft and CSRF attacks. The information provided by Origin--a bit of contextual request-creation information--should provide hints to web servers about trustworthiness of requests [...]
Checking the HTTP_ORIGIN
header could be written as :
header('Content-Type: application/json'); if (isset($_SERVER['HTTP_ORIGIN'])) { $address = 'http://' . $_SERVER['SERVER_NAME']; if (strpos($address, $_SERVER['HTTP_ORIGIN']) !== 0) { exit(json_encode([ 'error' => 'Invalid Origin header: ' . $_SERVER['HTTP_ORIGIN'] ])); } } else { exit(json_encode(['error' => 'No Origin header'])); }
1. (bis) Check the REFERER header
Again from OWASP :
If the Origin header is not present, verify the hostname in the Referer header matches the site's origin. Checking the referer is a commonly used method of preventing CSRF on embedded network devices because it does not require a per-user state.. This method of CSRF mitigation is also commonly used with unauthenticated requests [...]
Checking the HTTP_REFERER
is also quite simple in PHP with $_SERVER['HTTP_REFERER']
, you can just update the above code with it.
BE CAREFUL with the checking which always need to be really specific : do no check just example.com or api.example.com but the full https://example.com. Why ? Because you could spoof this check with an origin like api.example.com.hacker.com.
2. Generate CSRF tokens
A well-explained answer specific to PHP has been given there, in short :
Generate the token :
session_start(); if (empty($_SESSION['csrf_token'])) { $_SESSION['csrf_token'] = bin2hex(random_bytes(32)); }
Add it in your generated views via a meta (like Github) :
<meta name="csrf-token" content="<?= $_SESSION['csrf_token'] ?>">
Setup jQuery ajax calls to include this token :
$.ajaxSetup({ headers : { 'CsrfToken': $('meta[name="csrf-token"]').attr('content') } });
Server-side check your AJAX requests :
session_start(); if (empty($_SESSION['csrf_token'])) { $_SESSION['csrf_token'] = bin2hex(random_bytes(32)); } header('Content-Type: application/json'); $headers = apache_request_headers(); if (isset($headers['CsrfToken'])) { if ($headers['CsrfToken'] !== $_SESSION['csrf_token']) { exit(json_encode(['error' => 'Wrong CSRF token.'])); } } else { exit(json_encode(['error' => 'No CSRF token.'])); }
Most PHP frameworks have their own CSRF implementation, which more or less lay upon the same principle.
3. Sanitize validate user input.
You always must filter espace inputs and validate them.
4. Protect your server
5. Never trust user input
As @blue112 said, it is one of the most elementary security principles.
Short answer: you can't protect your client side.
Long answer:
You can't do anything to make the browser prove that it's actually your javascript code that runs on the client side. Then, the obvious action to take is the most simple one: NEVER TRUST USER INPUT.
This mean, as you started to do, securing your server side using session, rate limiting, data validation, fail2ban (banning a client ip after a certain number of fail), log monitoring...
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With