It's rare, but I have to pay MS a compliment: the ASP.NET WebMethod (AJAX) authorization is a dream, regarding my desire for security and laziness.
Encosia's ASP.NET page methods are only as secure as you make them absolutely fits those needs. ASP.NET is actually workable for me now. Free at last! (From the noble but disastrous AJAXControlToolkit).
Anyways, the problem is, that's for work. I'm not buying the MS architecture when LAMP's out there for free. I'm new to AJAX, and I can't seem to find a clear answer on how to authorize AJAX calls to PHP in the same way as Encosia above.
Can anyone suggest the PHP equivalent of what Encosia does in the link above?
Thanks in advance!
More Details
OK, let me be more specific. Encosia's solution above gives 401 denied to anyone not logged in trying to access a webmethod. Neat, clean, easy. Before, I tried to user session data to give access, but it, unknowingly to me, forced synchronous mode. Nono.
I need both, for my site. I need to be able to give 401 denieds on certain pages if a user isn't logged in. I need to be able to allow anyone to call other phps via ajax regardless of login.
Clarity
Bottom line: I don't want anyone accessing certain AJAX PHPs unless if they are logged in. I don't care what the response or any other details as long as its' still AJAX. How to?
Not really clear from the question, but if you want to only allow access to your AJAX server side listening scripts (maybe XML or JSON output) to users that have either authed or are on the related page,then how about adding a session identifier to your JS AJAX requests? In the server side script you can check that identifier against maybe a DB table holding your current sessions.
For extra security, you could check against IP, a cookie etc. These are all values that you can set when the session is started.
The main thing you need to ask yourself is this:
If a user is either logged in or browsing, what kind of access to the database do you really want / need to give? Each application will have its own needs. If you are going to have AJAX listeners on your server, then all that's needed is a quick look at Firebug (example) to see where your scripts are and the format of the requests. This could allow a potential security hole to be found. Make sure all your incoming requests are correctly treated so as to remove the possibility of injection attacks.
Related
There is any way to check the login status through different programming language?
Right now I'm using three session (same name) that starts at the same time after the login process, using ajax.
Right now, the login.html form is processed on three files: login.aspx, login.asp and login.php but it's seems too slow and weird. I'm combining three different services from the same company into one, after re-building the users and others common tables in mysql, everything seems to work fine, but I'm really scared about security bugs.
Just to let you you know, I have to check the login session status before any ajax callback, so if the user is working on an ASP page calling PHP through Ajax, may be that the session is still active on the ASP, but expired on the php file.
Any valid method to check all in one time? I can also accept a cookie solution but how to make it readable between php, asp and .net?
This sounds like single sign-on to me. Let's try to split the problem.
There is any way to check the login status through different programming language?
You're not really interested in the language used. Any language, given the same info and algorithm, would decode with success the same encrypted data. I guess you're instead having problems because PHP's application logic regarding this point is different from the ASP's one.
So for the first point, you can
Implement / normalize the same session checking logic among all of your apps. This is probably unfeasible, because you might be using Laravel here, and ASP.Net on the other, and the two are probably slightly different in this regard. If you can, do this, or...
Look into JSON Web Tokens. I won't go into detail, but these were more or less designed to solve this class of problems. They are also easy to handle, but be aware, there are aspects you have to take care of when using them for user authentication.
[...] Just to let you you know, I have to check the login session status before any ajax callback, so if the user is working on an ASP page calling PHP through Ajax, may be that the session is still active on the ASP, but expired on the php file.
Not to be that guy, but some concepts are somewhat deformed here. Sessions don't expire on files; they normally are setup with a given expiration time and a given domain. So generally speaking, a session opened from a PHP app, and stored on a cookie, then read from an ASP one shouldn't change, given that no difference exists between the two app's session handling logic.
Any valid method to check all in one time? I can also accept a cookie solution but how to make it readable between php, asp and .net?
For both of the solutions i suggested above is, especially for the cookie one, it's important you make the apps absolutely identical in respect to session handling. While this is trivial with JWT (as there's barely any logic on the app's side), this may prove to be harder with cookies if the authentication logic comes from some one else's code (as in a framework).
I haven't asked about single sign-out, and at this point i'm afraid to ask :). But these are some guidelines:
If going the cookie route, be aware of cookie's domain. A cookie is normally valid for every request coming from the website domain (name.com), but you may have some of your apps under a subdomain (like, phpapp.name.com). In this case, be sure the cookie created from the given app is valid for the whole domain, and not just the subdomain. And make the apps available at subdomains / pages under the same domain. Cookies don't work cross-domain, and you have to deal with that, since cookie domain policy is enforced at browser level.
Launching three AJAX calls means triggering three login procedures. I suppose all of these would terminate, at some point in the future, and all of those would be storing / rewriting the cookie. If the apps understand the same cookie, it's mandatory you open the login process on just one of them. This would store the cookie, which would then be automatically picked app from, say, a page in the second app, giving you a seamless transition into a logged-state in the second app.
JWT would normally require some JS work, which you may like since the same script can easily be loaded in all of your apps. On the other side, you can be sure that different server libraries handling JWT would all work the same for you, thus ensuring compatibility.
Personally, i would look into JSON Web Tokens.
You can develop your own session provider which stores data in a separate place (for ex. in database or files). Then everything you need to do is write some code in every environment to handle your session information from that provider. Because you use only one source to store session information there will be no problem with synchronization between any of yours environment.
If you need then you can use a webservice for exchange session information between every environment and session provider. Every application can use security connection to get and set information about session from that session webservice.
I think you can do this!You can create provider which stores data into database. Then Write some cool code to manage your provider.You can also use webapp or sevice.Every service use security to get and put information.
I'm currently writing an Android app at the moment, that accesses a PHP file on my server and displays JSON data provided by my MYSQL database.
Everything works great and I love the simplicity of it, but I'm not too comfortable with the fact that someone could just type in the URL of this PHP file and be presented with a page full of potentially sensitive data.
What advice would you give me to prevent access to this PHP file from anyone except those using my android app?
Thanks very much for any information.
The keyword is authentication. HTTP-Authentication is designed just for that purpose!
There are 2 forms of HTTP-auth:
Basic: easy to setup, less secure
Digest: harder to setup, more
secure
Here is the php manual.
And this is what you can do in your android app.
There isn't really a fool-proof way to do this. However you can require the user agent to match that of your application. You can also hide a private key in your application that is passed as POST data to your PHP file. Now, neither of these will stop someone who is determined to get at the raw output, but it will slow down the people who are just screwing around killing a little time seeing what they can accomplish.
Why not only enable a valid response if the request is sent with the following header:
Content-Type=application/json
If the request doesn't pass it as the Content-Type, then you just terminate the script (as regular browsers usually want to get text/html or similar things). It's not really worth locking everything tight shut, as if your app can get the data from your server, any user would have the opportunity too.
[I hope that this question is not too broad, I think that the subject is very interesting but I incourage you to tell me if it's off-policy.]
My scenario is this:
I have a LAMP website who stores also sensitive data and documents
Only registered users are allowed to operate on the site, and only on certain data and documents. Users are stored in $_SESSION variables
Most of the pages implement a sort of rudimental permission control, but some important DB operations are called via AJAX
AJAX security is implemented very poorly, as anyone that is that smart can tamper with the request sending whatever id they like and delete records with brutal simplicity
Asking for a complete book on security is obviously a bit too much (and I'm already reading and trying a lot on the subject), let's say that my main concern is if AJAX pages should be treated with special regards, as I need to secure the whole software to prevent hacks and other problems.
let's say that my main concern is if AJAX pages should be treated with special regards
Not really. They should be treated almost exactly the same as any other request. All HTTP requests come from outside your system and are under the control of the client (so can consist of, more or less, anything the user can imagine).
You might be returning JSON, you might be returning a complete HTML document, you might be returning XML — but the format doesn't matter, the data does.
If the request is for sensitive data, then you need (on the server) to authenticate the user and then make sure they are authorised to view / edit that data.
The only difference is how you present a "You are not authorised" message. You can't simply return an HTML document with a login form when you expect the browser to load data into XHR. The response needs to be appropriately formatted and the JavaScript needs to be able to handle it.
I have a LAMP website who stores also sensitive data and documents
You should store as little sensitive data as possible. Especially when you are not sure how to keep this information secure/private. Use OpenID or something for your authentication for example. I really like LightOpenID for it's simplicity. I created a little example project/library to see lightopenId in use. It simplifies using OpenID by using openID-selector. When you use OpenID you also use secure OpenID providers the passwords are also not transmitted over the wire in plain-text but protected by https/SSL.
Only registered users are allowed to operate on the site, and only on
certain data and documents. Users are stored in $_SESSION variables
Yup that's what sessions are for.
Most of the pages implement a sort of rudimental permission control,
but some important DB operations are called via AJAX
You should read up on OWASP top 10. at least. (Don’t stop at 10.)
AJAX security is implemented very poorly, as anyone that is that smart
can tamper with the request sending whatever id they like and delete
records with brutal simplicity
See previous section. Read up on OWASP top 10 section at least. Somethings which a lot of people overlook for example are CSRF for example.
I am designing a website, and I really want it to be as secure as possible.
I have a private folder that cannot be accessed (.htaccess) which contains all my php classes (and similar structures), and a public folder that has my Javascript, CSS and a PHP file for the Javascript(via AJAX) to interface with, which in turn accesses the classes in the private folder.
Now here is my issue, and for the life of me I just cannot seem to get my head around this one:
If someone was to look at the js code they would see the commands / data being sent to the publicly available PHP Script (as described above), therefore getting an idea of what commands to use interface with that script and potentially gain access to stored data etc.
now I know that ajax wont work remotely etc but as long as you got the commands from the ajax script you could interface directly with it, so i thought i would do a referrer check on the interface script and that worked perfectly until I realized how easy it was to spoof your referrer header!
does anyone have any ideas on how to secure this. if this just sounds like complete garbage tell me and I'll try and break it down further.
AJAX and JS are client-based - everything they do, any user can do. If you expose an API method to AJAX, you expose it to the user - there's nothing you can do about that. That's your design choice. You could of course obfuscate your API calls, but that doesn't really do anything other than make it less user-friendly.
The bottom line: don't trust any user input, regardless of whether it came from your AJAX code or somewhere else.
Well, someone scripting your site directly would only be able to access the same stuff he already can in UI, right?
If you have an script function doAdminStuff(), you would check server side if the user is logged in AND is an admin, before taking any actions
Relax, dude.
This is SPARTA! WEB.
Every site in the world is "exposed" like this. That's the way the web works, Ajax or non-ajax based.
You can't help it, yet there is no harm in this. There is nothing to secure.
Here are my recommendations:
Use SSL if you are not already.
Use a (software) token for all requests that you want to protect.
To discourage others from reading your javascript files, you can obfuscate them. Dean Edward's packer is a famous one.
Write a script that sniffs logs and data for potentially bad activity. If you are not logging all the activity you need to (like if the apache logs are not enough) consider writing activity to your own log.
don't be paranoid, just filter input params, maybe you should switch on SSL so you ajax requests content will be hard to sniff, etc.
Are you using the ajax-thing only for security-reasons or for any other reason? Because you can build up an architecture like this (a PHP-file as "gateway" and all other PHP-files in access-restricted folder) without using ajax as well. If you want to check out, you could take a look at the default folder structure of Zend Framework. This structure has the advantage that there is no logic visible for your users at all.
Also important is that IE (at least IE 6 & 7 I think) does not send a referrer at all by default so this probably wouldn't work anyway.
I have a script that uses JSONP to make cross domain ajax calls. This works great but my question is, is there a way to prevent other sites from accessing and getting data from these URL's? I basically would like to make a list of sites that are allowed and only return data if they are in the list. I am using PHP and figure I might be able to use "HTTP_REFERER" but have read that some browsers will not send this info.... ??? Any ideas?
Thanks!
There really is no effective solution. If your JSON is accessible through the browser, then it is equally accessible to other sites. To the web server a request originating from a browser or another server are virtually indistinguishable aside from the headers. Like ILMV commented, referrers (and other headers) can be falsified. They are after all, self-reported.
Security is never perfect. A sufficiently determined person can overcome any security measures in place, but the goal of security is to create a high enough deterrent that laypeople and or most people would be dissuaded from putting the time and resources necessary to compromise the security.
With that thought in mind, you can create a barrier of entry high enough that other sites would probably not bother making requests with the barriers of entry put into place. You can generate single use tokens that are required to grab the json data. Once a token is used to grab the json data, the token is then subsequently invalidated. In order to retrieve a token, the web page must be requested with a token embedded within the page in javascript that is then put into the ajax call for the json data. Combine this with time-expiring tokens, and sufficient obfuscation in the javascript and you've created a high enough barrier.
Just remember, this isn't impossible to circumvent. Another website could extract the token out of the javascript, and or intercept the ajax call and hijack the data at multiple points.
Do you have access to the servers/sites that you would like to give access to the JSONP?
What you could do, although not ideal is to add a record to a db of the IP on the page load that is allowed to view the JSONP, then on the jsonp load, check if that record exists. Perhaps have an expiry on the record if appropriate.
e.g.
http://mysite.com/some_page/ - user loads page, add their IP to the database of allowed users
http://anothersite.com/anotherpage - as above, add to database
load JSONP, check the IP exists in the database.
After one hour delete the record from the db, so another page load would be required for example
Although this could quite easily be worked around if the scraper (or other sites) managed to work out what method you are using to allow users to view the JSONP, they'd only have to hit the page first.
How about using a cookie that holds a token used with every jsonp request?
Depending on the setup you can also use a variable if you don't want to use cookies.
Working with importScript form the Web Worker is quite the same as jsonp.
Make a double check like theAlexPoon said. Main-script to web worker, web worker to sever and back with security query. If the web worker answer to the main script without to be asked or with the wrong token, its better to forward your website to the nirvana. If the server is asked with the wrong token don't answer. Cookies will not be send with an importScript request, because document is not available at web worker level. Always send security relevant cookies with a post request.
But there are still a lot of risks. The man in the middle knows how.
I'm certain you can do this with htaccess -
Ensure your headers are sending "HTTP_REFERER" - I don't know any browser that wont send it if you tell it to. (if you're still worried, fall back gracefully)
Then use htaccess to allow/deny access from the right referer.
# deny all except those indicated here
order deny,allow
deny from all
allow from .*domain\.com.*