I am having an issue that I hope you can help with. Let's say I work for a hypothetical company called "Blammo", and we have a hypothetical product called "Log". I am trying to set up a system where someone could log in to logfromblammo.com and order some of our products, and then when they are ready to purchase go to checkout.blammo.com to pay for their order. Eventually I want to allow for Blammo to launch a new hypothetical product with it's own website: rockfromblammo.com, and have that site also able to share a session with checkout.blammo.com so that users can have a single shopping cart across both product websites.
Naturally the hypothetical scenario described above is not how my company actually works, but it is a fair example of what I need to do. We have an existing user database, and we have ways to authenticate any of our users on any of our sites, but the goal I have is to allow users to cross seamlessly from one site to another without having to re-authenticate. This would also allow for us to seamlessly transfer data such as a shopping cart to the checkout site.
I have (briefly) looked at solutions such as OpenID, but I need to be able to integrate whatever solution we have with our existing authentication method, which is not terribly robust. Is there any good way to do this through PHP alone?
What you could do is create "cross-over" links between the sites to carry the session over.
The simplest way is to pass the session id via the query string; e.g.
http://whateverblammo.com/?sessid=XXYYZZ
Before you start thinking that anyone can trap that information, think about how your cookies are transferred; assuming you're not using SSL, there's not much difference for someone who taps the network.
That doesn't mean it's safe; for one, users could accidentally copy/paste the address bar and thus leaking out their session. To limit this exposure, you could immediately redirect to a page without the session id after receiving it.
Note that using mcrypt() on the session id won't help much, because it's not the visibility of the value that's the problem; session hijacking doesn't care about the underlying value, only its reproducibility of the url.
You have to make sure the id can be used only once; this can be done by creating a session variable that keeps track of the use count:
$_SESSION['extids'] = array();
$ext = md5(uniqid(mt_rand(), true)); // just a semi random diddy
$_SESSION['extids'][$ext] = 1;
$link = 'http://othersite/?' . http_build_query('sessid' => session_id() . '-' . $ext);
When received:
list($sid, $ext) = explode('-', $_GET['sessid']);
session_id($sid);
session_start();
if (isset($_SESSION['extids'][$ext])) {
// okay, make sure it can't be used again
unset($_SESSION['extids'][$ext]);
}
You need these links every time a boundary is crossed, because the session may have gotten regenerated since the last time.
It can be done, but not with simple cookies and it is not trivial. What you are after is a single sign on (SSO) solution, similar to Google's which share's login's across i.google.com, gmail.com, youtube.com etc.
I have used OpenID to implement this in the past.
The basic idea is to have a single authentication domain (Provider), whenever one of the sites (Consumer) wants to authenticate the user, they redirect them to the authentication domain. If they aren't signed in, they can log in using whatever details you require.
If they are already logged in (even from a different target site), they don't need to log in again.
The user is then sent back to the target site with the addition of a token in the url. This token is used by the target site's server to verify the user is authenticated with the authentication server.
This is an extremely simple explanation. Doing this is not difficult, doing it securely is much more so. The details of generating and authenticating the tokens securely is the challenging part. Which is why I suggest building upon a well designed system such as OpenID.
In cross domain Ajax, you may find that cookie and, followingly, session are lost for cross domain requests. In case you'll be making ajax calls from you site example.com to your subdomain s2.example.com you will need to use properties in headers for PHP:
header('Access-Control-Allow-Origin: https://example.com');
header('Access-Control-Allow-Credentials: true');
and in JS you going to add
xhrFields: { withCredentials: true }
Otherwise cookies are not passed and you can't make use of session on your subdomain.
Full JS request to subdomain will be without lost of session:
$.ajax({
url: "https://s2.example.com/api.php?foo=1&bar=2",
xhrFields: { withCredentials: true },
success:function(e){
jsn=$.parseJSON(e);
if(jsn.status=="success") {
alert('OK!');
} else {
alert('Error!');
}
}
})
You need to set the session cookie domain like so:
session_set_cookie_params($lifetime,$path,'.site.com')
This will only work if the sites are on the same domain name including TLD (Top Level Domain).
See here for more info
Alternatively, if you are looking at trying to access sessions cross domains, as in from site1.net to site2.com, then this cannot be done.
If it's OK for your site to rely on Javascript to function, you could presumably do something like the following:
Say you have a session on blammo.com and you want to access it from rockblammo.com. On the rockblammo.com page you could load a <script> from blammo.com/get-session.js, this will (from the server side) return the session-id. Once that returns, you insert a new <script> tag in the page, pointing to rockblammo.com/set-session.js?sessionId=XXX, where XXX is the session-id you just got from blammo.com. Now, on the server side of rockblammo.com, the session cookie is updated and set to this session-id. Going forward, the two pages will now share the same session-id, and assuming they have access to the same session store on the backend, they would be in sync.
E.g. the output from blammo.com/get-session.js would be:
var sessionId = "XXX";
var s = document.createElement("script");
s.src = "/set-session.js?sessionId=" + escape(sessionId);
document.body.appendChild(s);
The output from rockblammo.com/set-session.js would be blank, but would include a http header, such as:
Set-Cookie: sessionId=XXX
If you prefer not to rely on Javascript, you could probably do the same by redirecting forth and back between the two sites and passing the sessionId in a query-string parameter (GET param).
Related
I want to use post to update a database and don't want people doing it manually, i.e., it should only be possible through AJAX in a client. Is there some well known cryptographic trick to use in this scenario?
Say I'm issuing a GET request to insert a new user into my database at site.com/adduser/<userid>. Someone could overpopulate my database by issuing fake requests.
There is no way to avoid forged requests in this case, as the client browser already has everything necessary to make the request; it is only a matter of some debugging for a malicious user to figure out how to make arbitrary requests to your backend, and probably even using your own code to make it easier. You don't need "cryptographic tricks", you need only obfuscation, and that will only make forging a bit inconvenient, but still not impossible.
It can be achieved.
Whenever you render a page which is supposed to make such request. Generate a random token and store it in session (for authenticated user) or database (in case this request is publicly allowed).
and instead of calling site.com/adduser/<userid> call site.com/adduser/<userid>/<token>
whenever you receive such request if the token is valid or not (from session or database)
In case token is correct, process the request and remove used token from session / db
In case token is incorrect, reject the request.
I don't really need to restrict access to the server (although that would be great), I'm looking for a cryptographic trick that would allow the server to know when things are coming from the app and not forged by the user using a sniffed token.
You cannot do this. It's almost one of the fundamental problems with client/server applications. Here's why it doesn't work: Say you had a way for your client app to authenticate itself to the server - whether it's a secret password or some other method. The information that the app needs is necessarily accessible to the app (the password is hidden in there somewhere, or whatever). But because it runs on the user's computer, that means they also have access to this information: All they need is to look at the source, or the binary, or the network traffic between your app and the server, and eventually they will figure out the mechanism by which your app authenticates, and replicate it. Maybe they'll even copy it. Maybe they'll write a clever hack to make your app do the heavy lifting (You can always just send fake user input to the app). But no matter how, they've got all the information required, and there is no way to stop them from having it that wouldn't also stop your app from having it.
Prevent Direct Access To File Called By ajax Function seems to address the question.
You can (among other solutions, I'm sure)...
use session management (log in to create a session);
send a unique key to the client which needs to be returned before it expires (can't
be re-used, and can't be stored for use later on);
and/or set headers as in the linked answer.
But anything can be spoofed if people try hard enough. The only completely secure system is one which no-one can access at all.
This is the same problem as CSRF - and the solution is the same: use a token in the AJAX request which you've perviously stored eslewhere (or can regenerate, e.g. by encrypting the parameters using the sessin id as a key). Chriss Shiflett has some sensible notes on this, and there's an OWASP project for detecting CSRF with PHP
This is some authorization issue: only authorized requests should result in the creation of a new user. So when receiving such a request, your sever needs to check whether it’s from a client that is authorized to create new users.
Now the main issue is how to decide what request is authorized. In most cases, this is done via user roles and/or some ticketing system. With user roles, you’ll have additional problems to solve like user identification and user authentication. But if that is already solved, you can easily map the users onto roles like Alice is an admin and Bob is a regular user and only admins are authorized to create new users.
It works like any other web page: login authentication, check the referrer.
The solution is adding the bold line to ajax requests. Also you should look to basic authentication, this will not be the only protector. You can catch the incomes with these code from your ajax page
Ajax Call
function callit()
{
if(window.XMLHttpRequest){xmlhttp=new XMLHttpRequest();}else{xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");}
xmlhttp.onreadystatechange=function(){if(xmlhttp.readyState==4&&xmlhttp.status==200){document.getElementById('alp').innerHTML=xmlhttp.responseText;}}
xmlhttp.open("get", "call.asp", true);
**xmlhttp.setRequestHeader("X-Requested-With","XMLHttpRequest");**
xmlhttp.send();
}
PHP/ASP Requested Page Answer
ASP
If Request.ServerVariables("HTTP_X-Requested-With") = "XMLHttpRequest" Then
'Do stuff
Else
'Kill it
End If
PHP
if( isset( $_SERVER['HTTP_X_REQUESTED_WITH'] ) && ( $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest' ) )
{
//Do stuff
} else {
//Kill it
}
If I have an AJAX call to a php script, like this (using jQuery)
$.ajax(url: "../myscript.php");
and myscript looks like this:
<?php
//code that does something to db
?>
I want to know how to prevent a user from just going to example.com/myscript.php to execute the script.
Ajax queries are just user queries
Every XmlHTTP request can be replayed and tampered (just check your favorite browser console, capture the POST or GET requests and check if there is a replay options), you can also try Live HTTP Headers module (or many more) and capture anything to replay it.
So if you set an entry point in your application, anybody can try to access it and inject some bad stuff there.
Note that they can also alter any HTTP headers in their requests to alter things like the referrer page or the host header, anything.
Insecure Inputs
So in term of security every user input has to be considered unsafe (GET parameters, POST data, used url -- OMG so much application are never filtering data coming from the url path --, cookies, ...)
Filtered output
So you may wonder "How can I do something with insecure inputs?", well ...you can. The rule is to filter all the outputs. Take the output canal (database storage, html page, json response, csv file) and escape your data accordingly (htmlentites for HTML, json escapes for json, sql escaper or parametized queries for SQL queries -- check the libs--), especially the parts coming from the user input, which are really unsafe as stated before.
Access control
Now your main problem here is access control, you have an entry point where you perform some database actions and you do not want anybody to access this entry point and perform actions.
Several things to do:
ensure this is not a GET entry point (only POST, PUT, DELETE HTTP actions should perform modifications on the database), this will prevent usage of this url in an image tag later, loading the action without user interaction.
manage a user session, using cookies (PHP does that for you) you can share some data between several HTTP requests, this is called a session. The user cookie will be used to load the server-side session storage, containing important data, such as Is my user an anonymous user or a connected one?. This is the Identification part.
manage log-in log-out pages to get the Authentication part, theses pages will feed the session with the logged-in status. For a simple solution you can also check for HTTP basic authentication (.htpasswd files), it will also work for ajax, but never use HTTP basic Authentication without SSL. This Http auth mode will manage both identification and authentication parts.
manage ACL (Access Control List), the way you want, and use that to decide if your ajax page can be accessed by the current user (you get the user from the session). If not, send a 403 HTTP response.
Public Access
Now if your 'database' stuff that should run is not related to any user privilege, but you just want to prevent abuse of it, like, say, a statistical ajax query, doing a counter increment, that every user should call at least once. In this case you will have some problems. It's very hard to prevent abuse of a public entry point (just think of how hard it is to protect websites from DOS and DDOS). You'll have to build a functional system, application-based, things like generating a unique token in the user page and checking that this token is used only once (but an anonymous page could be used by thousands of users, coming from a proxy cache), maybe you'll have to record user IP and restrict the token usage by IP (but some users may share the same IP), or maybe you'll have to send the unique token to the user using ajax.
We could talk of a lot of things, but that depends on the things you are trying to do. The important thing are:
never trust user inputs
filter outputs
manage sessions and ACL
never consider anything as hidden, there's no such thing.
Some answers here give you an overview of the concepts behind your question, let me give you a more pragmatic approach (you should at least read and understand what others say about this matter though!).
You just need to ask yourself: Do your app must enforce that all requests to myscript.php should be controlled?
If so then you need to use some sort of token: you create a token and send it to the client (browser), then the browser must send back the token and you check if it matches before doing some action:
<?php
// somefile.php (this file serves the page that contains your AJAX call)
session_start();
//...
$_SESSION['token'] = createNewToken(); // creates unique tokens
//add the token as a JS variable and send it back in your AJAX CALL
// some where you'll have something similar to this:
<script>
var token = <?php echo $_SESSION['token'] ?>;
$.ajax({
url: "myscript.php",
data: form_data, // include the token here!
//...
})
And then in your script:
<?php
// myscript.php
session_start();
// you can check if it's an AJAX call, if the user is logged and then the token:
if (!isset($_SESSION['token')) {
header("HTTP/1.0 403 Forbidden");
die("Direct access not allowed!");
}
// Assuming your AJAX is a POST though you didn't tell us
if (!isset($_POST['token'] || $_POST['token'] != $_SESSION['token']) {
header("HTTP/1.0 400 Bad request");
die("You didn't provide a valid token!");
}
// do something with your DB
Otherwise you just need to check if the user is logged as you would normally do with the rest of your scripts:
<?php
// myscript.php
session_start();
// Check if logged in user
if (!isset($_SESSION['loggedIn']) || !$_SESSION['loggedIn']) {
header("HTTP/1.0 403 Forbidden");
die("You need to be logged in!");
}
// Do something with your DB
TO SUM UP
Using the first method allows a more controlled access as you force the user to send a secret (the token, which will be different in every request) that a normal user won't have (if some other user gets the token, then you have bigger problems like session hijacking). Notice that this method prevents the user opening on multiple tabs / different browsers as only the last token will be saved. In order to avoid that you have this fantastic answer on SO
On the other hand, the second approach allows (logged) users to request directly your myscript.php, but maybe you don't need to prevent that (if you need, just use the first method). Notice here you won't have the issue of multiple tabs / different browsers as you'll only check if the user is logged in.
how to prevent a user from just going to example.com/myscript.php to execute the script
From a security perspective, the AJAX call is the same as the user going to that URL. That is, the human user and the script you use to make the AJAX call are part of the same security principal. If you don't trust the user with access to the PHP script, you can't trust the JavaScript running on the user-controlled computer either.
So in what cases can there be separate security principals? You could, for example, only deploy the client JavaScript on some kind of tamper-proof kiosk. That way, you could store a secret value in the kiosk, shared with the server. The kiosk would send the secret value with each request for the server to validate.
But if you're doing this for a usability reason, to prevent accidental invocation of the script, then yeah, maybe try that one thing Dirk Pitt linked to.
I've got a page under http://www.example.com/abc/def/a/ where a user can buy products.
For a marketing activity (printed paper) the customer should type in a shorter url
http://www.example.com/order/
When this url is called, the server executes this script:
<?php
header("Location: http://www.example.de/abc/def/a/");
exit;
?>
The page under http://www.example.com/abc/def/a/ contains some
informations (rebate-code etc.) which should only be visible to users
coming from http://www.example.com/order/
$_SERVER['HTTP_REFERER'] seems to be not reliable from what I've read.
I checked with phpinfo(); if there is any info variable which contains "order" but I haven't found one.
Is it possible or do you recommend an alternative approach?
HTTP is in it's pure form a stateless-protocol, so you won't find anything in the protocol itself that will help you with your current problem.
Using $_SESSION to store data in-between requests is the easiest route to walk, and what I recommend.
As said; since the protocol used to transfer information is stateless you have no choice but to create a method for your web-application to recognize which request is done by which user.. this is a perfect problem solved by php-sessions.
php.net - PHP: Sessions - Manual
As you have discovered, the HTTP Referer, along with all of the other headers, can easily be faked. The only reliable way I see of accomplishing this is logging users as they visit the orders page and when they visit the /abc/def/a/ page, verify that the log entry exists. This kind of log could be stored in $_SESSION, however be sure that when using multiple servers you have the proper setup to ensure all servers share the same session information (you can use a redis server to store session data).
On the order page:
session_start();
$_SESSION['order_visited'] = true;
On the rebate code page:
session_start();
if(!isset($_SESSION['order_visited']) || !$_SESSION['order_visited']) {
header('Location: /order'); // Must visit order first
die();
}
Background: I have a website, which we'll call AwesomeSite.com; it handles all of my traffic. Additionally, for the purposes of marketing I have a second domain, which we'll call PromoForAwesomeSite.com; it redirects all traffic straight to AwesomeSite. Both sites are built using PHP, MySQL, and Apache.
Problem: I want to serve up different content to users based on how they came to my site. Specifically, I want to show promos if the user was redirected from PromoForAwesomeSite.
Question: How can I detect that a user came from PromoForAwesomeSite and thus create a different session state for them?
p.s. I am well aware of the shortcomings of this approach, in that once a session cookie is deleted promo users cannot see the promo content unless they revisit the redirect site (not likely). Unfortunately, this cannot be helped.
You can utilize the $_SERVER['HTTP_REFERER'] and see if contains the PromoForAwesomeSite.com in the referrer string. For instance something like this:
session_start();
if(substr_count($_SERVER['HTTP_REFERER'] , 'PromoForAwesomeSite.com')){
$_SESSION['from_promo'] = 1;
}
As referrers can be blocked by the browsers, so you might look into the possibility of sending a GET param in the redirect string from the promo site. Not sure how you are redirecting from your promo site but if its PHP you can do something like this , if not you will get the idea what I mean :)
HEADER('Location: http://AwesomeSite.com/index.php?from=promo');
So instead of (or in additional to) checking the referrer you can also check for this string and save in the session.
In your case the referrer won't be carried on if you do an automatic redirect at the landing time. Thus, If I were you, I would handle it like this:
1. On PromoForAwesomeSite.com
header('Location: http://www.awesomesite.com/promo.php');
2. On AwesomeSite.com
a. Create a promo.php gateway page
b. On the gateway page
setcookie('Promo', '1', time()+(5 * (24 * 3600))); // five days promotion cookie - adjust it
header('Location: http://www.awesomesite.com/index.php');
c. On the index.php
if($_COOKIE['Promo']){
// show promotion
}
This way you will solve the issue with the session as well.
two years ago I had to design a system to share authentication data across multiple domains, all of them shared the same server/db. I was able to pull this off with a complex system of cookie sharing which, to date still works.
I'm now in the process of redesigning the system and I was wondering if there are better ways to achieve this without having to write cross domain cookies.
Basically the system MUST do this.
Once logged in one site the user must be logged in all of the other site seamlessly, not only following a link, but even by directly writing the domain name on the address bar.
To my knowledge the only way to achieve this are cross-domain cookies, if there are alternatives please tell me.
Thank you very much
My Idea would be to include a login-Javascript from a third domain which gets includet in all sites. This javascript sets and reads the session-cookie and calls the current domains server via ajax with the result. (No validation should be done in the JS - this simply sets and reads the cookie)
If cross domain AJAX does not work, you can still call the thirds domain server which acts like a proxy and calls the current domains server.
The StackOverflow sites have implemented something similar to this. Check out the details at the following links.
Here is a post giving an outline of how they did it.
And here is even more detail.
For this you do have to use cookies, but you can vary what you store in the cookie. The cookie doesn't have to contain user credentials but can instead contain something more like a token that you use to "centralize" your sessions.
Easies way would be to let all hosts share a single memcached server and use the content of the users cookie as your key.