Take Facebook's reply-to-status as an example. When you replies to someone's status, does the script looks into the DOM of that status for the ID of that status, and send an Ajax to update the entry with that ID?
If that's the case, couldn't you just modify the ID and pollute the data
P.S. as a followup, I've seen a client-side MVC implementation, Backbone.js, that manage things like the above w/o the use of any ID, which I still haven't figured out how.
http://documentcloud.github.com/backbone/docs/backbone.html
Here is the source, the relevant code 'view' starts at last 1/4
It will still verify that it's a valid id on the server side, that you have permissions to follow up to that user's statuses, etc.
Yes you can, but keep in mind it's all session/friends list/permissions based too.
There are still checks involved on the server regarding "does user A have access to making a comment on user B's action". Assuming you type a bogus ID, it still needs to be verified you can post on the (spoofed) ID.
If you can, you just made a post on a completely separate topic which is now presumably out of context.
If you can't the post doesn't go through and no worries.
What it comes down to is that the UI is a "convenience" check. There's not real integrity to validating other than gently guiding the user to travel the correct path. The server is where the real protection is because, as every real programmer knows, the user can not be trusted.
Related
Upon completion of an ajax call I would like to direct the user to an html page, but at the same time passing a hidden variable (this variable contains sensitive information and should not show up in the URL).
How can I accomplish this?
window.location.href = 'userpage.html?id=14253';
But with the id remaining invisible? Can I POST the id somehow while sending the user to userpage.html?
You should not be checking user credentials on the client side of your website. Regardless of how the ID is being passed to your script, it can be replicated without you being able to check if the request is valid.
To start being even remotely secure with what information is granted to a user, you need to be checking it via the server side. With every request, ensure the user is authenticated to view such data.
If I were you, I would look into using PHP sessions as the first line of defense for checking if a user is authenticated. Doing so will at least keep the information about a user out of a replicable space that can be viewed by the user.
Look up 'php session login tutorial' on Google and you will find plenty of simple tutorials which should get you on the right track.
Example Tutorial
No matter what, the information you pass along is insecure. You can submit a post request using XMLHttpRequest objects if you'd like (or use a framework/library to make AJAX calls) -- but the user could still spoof the data and get different results.
ID enforcement should be done in the backend. Does the requested ID match the ID of the user signed in? No? Don't show it. etc etc.
I allow my users to favorite an update or a forum topic.
So when a user tries to favorite one of these i will send via Ajax 2 things, the item_id(update or topic) as id(ex. 1321313213) and its type("update" or "topic") as string.
However lets say someones tries to favorite an update with the id untouched but the type is changed to "topic"(via firebug or whatever else)...
This should not procceed since this combination is not correct... how can i assure that the item_id being sent is an update or a topic since this ID might co-exist in both tables???
Current solution:
Create a hidden input element and add as value 5 random characters (a-zA-Z0-9) and md5 type name(update or topic)
like:
$random_str = $this->my_model->generateRandomString(5);
<input type="hidden" value="<?php echo $random_str.md5("update"); ?>" id="type" />
so when i try to validate the data to check if it is an update or topic i split the type on the first 5 characters and later and check if the later characters are md5 hashed are update or topic and continue validation
I would like some help in case this can be altered as well...
Your server side script (PHP) must always assume it's getting bogus data. Never rely solely on javascript to handle any sanitization / verification.
If your javascript can determine if the job should be "update" or "topic", I'm sure your PHP can do that as well. Probably using a few more DB queries or some such, but that's the price you've got to pay.
Your are looking at the problem from the wrong perspective. Especially from You server side (PHP) code.
Your server gets data. It gets data which is something like that: user (from session), id and type. Your server needs to ask a question: is it valid data? If it is -- save it to DB; If it is not -- do not save it to DB. It is that simple.
You can look from this perspective: Your client side code is just one way to communicate with Your server. Another way is using web browser + firebug. It is perfectly valid usage of Your server side application. And Your PHP code should not care how request reaches it.
So if Your current code does not allow You in Your PHP code feel comfortable and freely decide if is it update or topic creation than Your need to change Your server side code (and perhaps DB schema) as well.
Your current solution is not good, because if I know how to use firebug I would probably find out that "9d9b68ac2b1de18d3712096354b3c3a5" means "topic" and "3ac340832f29c11538fbe2d6f75e8bcc" means "update".
I think Your are trying to invent Your own CSRF protection. So go on Internet and read about it.
This is sort of a generic "Good Idea/Bad Idea question".
My scenario: I am writing an ASP.NET MVC3 app that is just 1 page (one View/Controller). This view shows a grid of "Cases" and when a user clicks one of these Cases, I use jquery ajax ($.ajax) to swap out the visible portion of the page and load the details of this Case (but never change the page).
Still with me? Thanks!
Now, once this new Case detail view is shown, the user can edit the Case in one of many ways. Change the priority, change the status, etc. I am using jquery's ajax function for this as well.
My question: How should I store the Case ID? Is it ok to store it in the HTML? Is there a better place to store it?
All of the Cases have a Guid ID, and currently when the Case details are loaded (using ajax) I add a custom attribute to the Case detail view <div> so I know the Case ID. This means that the Case ID is visible to anybody viewing the page source. I thought about using jQuery's .data() function to store it, which wouldn't be visible to page source, but would be accessible from Firebug other inspector tools.
What is the best practice for this? I really can't imagine how my user's would do anything with the Case ID, but I am trying to be a bit paranoid here.
Thanks in advance for any thoughts! And thanks for reading this novel!
There's very little you can do about things which the browser gets to see in any fashion, since code and data in the DOM are not protected from the user.
Obviously you don't want to send anything to a user who is not allowed to see that information - so you don't want to do any client-side filtering of data that is dependent upon user role.
But as for internal data, you just have to protect your perimeter - methods can't accept ids which are mismatched (i.e. an account id which is only valid for a different customer being submitted) - but there's very little you can do about the ids themselves.
By sending the case ID from the server to the browser, you are giving it to the user. If you don't want the user to have the case ID, don't send it to the browser.
I'd provide some sort of sanitized, "imaginary" ID if you're that concerned. If this were running in a loop, I'd suggest basing it on the loop index.
Ultimately however, you'll need to use some sort of unique identifier on the Case that will identify it in ajax calls to the database.
Really though, I've done the same thing before and just encoded the ID field in the markup, and it's rarely mattered. This ID is only a harmful thing to have out in the open if your security is lax. If you've secured your database and have a decent level of security on the app, then you should be fine. If you haven't, then you have bigger things to worry about than markup.
I've got a site where users extend their product trial with a registration code. They click a link (with a key in the URL) from an email, get to this site and a lightbox appears with their registration code. I'm currently displaying the registration code with HTML and hiding it with CSS. Once I check to make sure the URL has the correct key with javascript, I display the registration code. However, this means anyone can just view source on the page and copy the registration code. Is there a way to encrypt the code so it doesn't appear in view source, and then decrypt it if the URL has the correct key? It's one code per product, not per user, so I don't have to do any server side authentication.
If the computer knows it, the user knows it.
You can play obfuscation games, all of which amount to making your Javascript hard to read. But a sufficiently determined user will find it anyway, and once they do, they can easily share it with their friends.
One code per user is the only way to fix this reliably.
I check to make sure the URL has the correct key with javascript
Don't check the key client-side, validate the key on the server.
This is the only way to ensure only valid users get the registration code.
Pseudo PHP example:
if( validateKey($_GET['key']) ) {
echo 'The Registration Code';
} else {
echo 'Error';
}
Client Side Code is inherently insecure. Consider anything you send to a client machine public to the world, and don't trust anything that comes from the client until you cleanse it. A sufficiently determined user will de-obfuscate your code, regardless how much effort you put into the initial obfuscation routine.
Another tip to help you instead to show the registration code in the site you can send back an email to the user with the registration code.
And as Nemo suggest, the right way is one code for user
Hope it help
As mentioned before the client side will not cover your security needs.
Better would be to have the page send a Ajax request to the server containing the key, you can then respond with the registration code.
Even better would be to directly validate the key on the first request, then decide to return an error page or the page with the registration info.
As others have replied, doing this validation server-side is both easier and more secure.
You can have an AJAX request posting the URL key to a php page, that in turn would reply with the correct registration code.
That being said, there is always the possibility of using a client-side use encryption library (like AES), but from what i understand i don't think it would be a good approach to solving your problem.
Again, doing it on the server-side is both extremely easy and as secure as you need.
Encrypt your registration code (plus some magic cookie) with the key in the server before embedding it in your HTML. In your JavaScript, validate the key (which comes in the URL) by decrypting the registration code. If the magic cookie matches, then you get a valid key and you can display the registration code to the user.
View Source will only reveal the encrypted registration code. Without the key, the snooper has no way to extract the registration code.
This means that you'll have a unique key per registration code, which should be the case for your registration system. The key you send to the user in an email, embedded into a link which they click as you said.
I'm debating the best way to propagate fairly complex permissions from the server to an AJAX application, and I'm not sure the best approach to take.
Essentially, I want my permissions to be defined so I can request a whole set of permissions in one shot, and adjust the UI as appropriate (the UI changes can be as low level as disabling certain context menu items). Of course, I still need to enforce the permissions server side.
So, I was wondering if anyone has any suggestions for the best way to
maintain the permissions and use them in server code
have easy access to the permissions in javascript
not have to make a round-trip request to the server for each individual permission
Thoughts?
If you have a clear set of permissions, like a "user level" or "user type", you could just pass the value down in a hidden field and access the value through the DOM. You could still do this if your permissions were more granular, but you would either have a lot of hidden fields or you would have to encode the information into XML or JSON or some other format.
You might set them as bit flags so that you could OR a single numeric value with a mask to see if the user had the permission for a specific activity. That would be very flexible and as long as you don't have more than 32 or so specific "rights", that would allow for any permutation of those rights in a very small package (basically an unsigned int).
For example:
0x00000001 //edit permission
0x00000002 //create new thing permission
0x00000004 //delete things permission
0x00000008 //view hidden things permission
.
.
.
0x80000000 //total control of the server and everyone logged in
Then a user with a permission of 0x000007 could edit, create, and delete, but nothing else.
In either case, I think you're on the right track - make the request once per page invocation, store the permissions in a global JavaScript data structure, and go from there. AJAX is nice, but you don't want to query the server for every specific permission all over your page. You would do it once on the page load, set up the presentation of your page and save the value in a global variable, then reference the permission(s) locally for event functions.
If you transmit the permission structure to the client as a JSON object (or XML, if you prefer), you can manipulate that object with the client-side code, and send it back to the server, which can do whatever it needs to validate the data and persist it.
I don't necessarily see it as the most "correct" solution, but would it be possible to keep all the permission stuff on the server side, and just serve the updated UI rather than some kind of JSON permissions system?
You'd have to make the decision based on how busy and intensive your app expects to be, but definitely a decision worth making either way
Encode them as JSON.