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.
Related
This question already has answers here:
How do I hide javascript code in a webpage?
(12 answers)
Closed 9 years ago.
is it possible to hide codes written in java script (j query)?
i have written a program and i have used two much load() function .
every one can see my pages address is it a risk?
something Like this:
load('account/module/message/index.php');
load('account/module/ads/index.php');
load('account/module/stat/index.html');
No.
JavaScript is client side therefore all code written is, in some fashion, directly visible to the client (end user). You can obfuscate it and make it more difficult to decipher, but in the end is still accessible.
If security is of concern you can keep "business logic" within php and access it using JavaScript (e.g. Ajax calls) but the end points would still be visible.
On every site that uses Javascript, that javascript code is visible to the end user. Not only that, but the end user is able to debug it, and change the either the variable contents or even the code itself at any moment.
Despite this, millions of sites use Javascript, and many of those sites are considered secure. The point is that while JS code may be visible to the end user, it doesn't necessarily mean your system is insecure. You just have to write your system with the understanding of how it works.
Here are some pointers:
If you put secrets (eg passwords or business logic that must be kept private) into your JS code, then those secrets are not secure. Don't do this; keep those details on the server.
If your JS code does any kind of validation, then that validation could be bypassed, so your server-side code must also do the same validation.
If your JS code makes calls that run code on the server (eg your load(...) calls, then the server must verify that the user has permission to do so; don't rely on the JS code to do that check.
You can't "hide" the client-side code, the most you could hope to do is obfuscate it, which to me is largely pointless in the context of the web - code that is delivered to the client should be exposable without being dangerous - and you can hardly obfsucate URLs, anyway.
For parts that shouldn't be exposed, don't expose them. Do server-side generation and output only what is needed, what is "safe"; some trouble can come when mixing the two (say, wanting to hide away logic by doing it on the server, but still deliver it dynamically using AJAX), because your logic is indirectly exposed (that is, although it can't be seen, the results can be gathered, perhaps from a different domain to use your content, etc.)
You can try using an Obfuscation Tool like YUI Compressor http://yui.github.io/yuicompressor/
So your code will not be readable for end user... but hidding it it's impossible
Hidding values and stuff
If you want to keep your values private, so user can't read them obfuscation won't be really your choice, but of course your source will be minified, it will be a mess if you want to read it, but it's still there...
So your choice here is use some kind of encryption which will be decrypted when page loads, but it is a hard work, you can use base64, sha1 or whatever you want only the strings or values you want. But anyone can decrypt it if they really want to.
Definately not, because javascript executed client side so either if possible you do all the operation on server side scripting ( jsp/php/asp) or minify/compress your javascript code after moving it to a sepatate file.
Unfortunately not.
Javascript runs on the client machine in the web browser and cannot be hidden from someone looking at the source code.
However this does not pose a security risk for your application provided nothing internal is visible should you visit those pages in your browser.
process all your "secret" code on the server, where the user doesn't have access to the code. Send only "non secret" things to the client, like for the UI. If you can't avoid sending secret code to the client, obfuscate it to make it more difficult to read.
Put your Javascript code in external file.
And then minified your javscript code, may this helps you.
To Convert Normal Javascript into Minified Javascript Refer this http://jscompress.com/
Well, I have a completely AJAX driven site. I inserted a jQuery code that affects all forms and queries site-wide. It's to the point, even though I want to change it, I fathom and accept the idea of a website that utitlizes a single function to process all queries (search, links, & profile, etc....)
How do you accomodate speed and security to such a platform? My php files can be accessed directly from their location's link. That is a threat. Help me; as well as AJAX, I need validation and '777' protection.
Before you read my answer read also this (as answer to a comment on your question) : Possible to view PHP code of a website?
Don't put speed and security in the same box. A website can be secure and fast at the same time.
I would secure a folder with 777 access (why not 755?) with an empty 0Kb index.html file (yes, even if you have inside a bunch of .php files!) ad put an .htaccess with restrictions deny from all that allows a folder to be accessed internally but not from 'outside'.
Than I would NEVER send sensitive data through the requests, but rather a client-side transformed Hashing algorithm like MD5 or SHA1 to compare data and validate on server-side. So don't ever ever send sensitive data in it's pure state over the yellow wire.
Need more security? https
Regarding a "single function" that drives your JS client-end of the site, well, if well formatted the browser doesn't care if it's one or hundreds, a good code is a readable code. Performance wise there's lots of suggestions on the www how to speed up your code.
To add to a really good #Tim's comment/tip, you can still open your console in Firebug (Net) and inspect every single piece of information that is sent from your Page to the server (and vice-versa!!) and act accordingly.
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.
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.
This is a question of security, so I am not looking for a solution on how to do this, I just want to make sure that it cannot be done.
Let's say I have a file called login.php and it's hosted online and running live, let's say on http://www.rimmer.sk/login.php
Now, let's image this file looks like this:
<?php
if (isset($_POST['register'])){
echo 'all is done !';
}
?>
Question: Can you, externally, send $_POST['register'] to my file, or can this be done only internally from files hosted within the same virtualhost?
It can be done. Everyone can send you a POST (or a GET, for that matter) request. There is no limit that forbids requests from outside your virtualhost.
(maybe not for you, maybe it is, but not everyone can set your $_SESSION, so an external domain cannot alter that)
In short yes it can be posted from the external site.
Yes this can be done very easily. Take a look at: http://php.net/manual/en/book.curl.php
Of course I can post from an external location, after all that's what the user's browser does when they submit the form. I can therefore write a script to post the register field to your server with ease.
What use case are you imagining? There are lots of security options (firewalls etc) but without knowing what you are trying to achieve, it's hard to give specifics.
One way of denying script attacks is to generate one time passwords on the server that you send to the browser with each registration form, then when you get a response back, check that the OTP is valid. This at least adds another layer of security.
But as I say ... without knowing more it's hard to be specific.
or can this be done only internally from files hosted within the same virtualhost?
Quite contrary. This cannot be done only internally. In fact, a form being sent not from server internals but from the user's browser