The problem
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.
The approaches
I currently have (for the login example I have included below):
- SSL Cert/HTTPS running on the domain.
- Certain AJAX request (obviously not this login request example as there is no session to begin with) will only work if the PHP Session is valid across the site (used on both
login.php
andapi.php
in this example). - Rate limiting on
api.php
when accessing functions. - PHP PDO prepared statements when interacting with the database inside
api.php
. - Encrypts sensitive data inside
api.php
(not relevant to the question).
The questions
Finally, my questions are:
- Is this approach to using asynchronous HTTP (Ajax) requests safe enough to use rather than just submitting data to a PHP page and redirecting onwards? (As this way improves the user's experience).
- How can I check to know that the data my user's are sending hasn't been tampered with?
- Am I reasonably doing enough to protect my user's data, if not, what else can I do?
The example
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"
});
}
1. Check the ORIGIN header
As specified by OWASP, this is not enough but recommended :
And by Mozilla :
Checking the
HTTP_ORIGIN
header could be written as :1. (bis) Check the REFERER header
Again from OWASP :
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 :
Add it in your generated views via a meta (like Github) :
Setup jQuery ajax calls to include this token :
Server-side check your AJAX requests :
Most PHP frameworks have their own CSRF implementation, which more or less lay upon the same principle.
3.
Sanitizevalidate user input.You always must
filterespace 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.
the best way is still to do server side securing and if i was a logged in user in the site i would also be able to check the csrf token on my meta tag and forge a script to the server. So the sure bet is server side validation
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...