Cross-site scripting

I'm kind of new to the whole security of my web app business, and I'm a little worried about people being able to access and execute my server-side code without permission (or by tricking someone with permission).

What's to prevent Johnny Malicious from creating a script that uses a ScriptTagProxy to connect to one of my arbitrary server-side code files to perform a malicious task?

I'm in a situation where the user required no login/password, but instead to have entry based around their Windows Authenticated Login. I could make it more difficult for Johnny by simply examining his login versus the permissions of his login, but what's to stop him from sending a link off to Bobby Admin and letting him execute it, etc..

What is the benefit of HttpProxy and Connection which make use of same-origin policy when script kiddies can just use ScriptTagProxy?

Now that I think about it you could, via firebug or fiddler or whatever, just examine the js files downloaded, pick one out (say EditUserPermissions.js), examine that file to find what server-side connection it makes to update the database (say EditUserPermissions.aspx) as well as examine the required params, and type it right into your browser. Johnny would be in the same situation as before where he might need to pass the url off to Bobby Admin, I guess, but it sure seems so easy..

the short answer is that there is nothing you can do to prevent people from accessing your backend scripts in any manner the choose. this means that your backend scripts MUST contain security checks to prevent malicious use.

the short answer is that there is nothing you can do to prevent people from accessing your backend scripts in any manner the choose. this means that your backend scripts MUST contain security checks to prevent malicious use.

It sounds as though the original poster has windows integrated security enabled on his web server so the issue is can a malicious script can hitch a ride on an established integrated security browser session?

If the OPs web server validates all user input to prevent upload of a script disguised as form input data, what other risks remain?

This is a subject I need to know more about but providing the OPs site does not include any voluntary mesh-up elements and all input data is validated, is the site safe?

It sounds as though the original poster has windows integrated security enabled on his web server so the issue is can a malicious script can hitch a ride on an established integrated security browser session?

If the OPs web server validates all user input to prevent upload of a script disguised as form input data, what other risks remain?

This is a subject I need to know more about but providing the OPs site does not include any voluntary mesh-up elements and all input data is validated, is the site safe?

Well, you say 'web server validates all user input to prevent upload of a script disguised AS FORM INPUT DATA', who's to say any of my server-side files are expecting form input data in the first place? It would be nice if it was just form input data that I was dealing with as that would fall into the realm of same-origin policy objects and would prevent exploiting as far as scripting and disguising.

I'm not sure what you mean by validated, do you mean in terms of preventing injection attacks by means of checking lenth/types/etc? Injection attack protection isn't an issue and has been taken care of.. it's simply a matter of making use of a server-side file that anyone can use, barring they aren't permitted..

Let's say an admin or permitted user has permission to execute a function in the web app which executes foo.aspx?bar=1337 which allows the user with ID #1337 permission to do whatever he wants. So Johnny Malicious comes along and puts mywebsite/mycode/foo.aspx?bar=42 in his browser, allowing him, a low level user of my site, to do whatever he wants. Of course, as devnull mentioned, a security check from within the server-side executable would prevent him from doing so, however, in my case, a login spoof or disguised script would work its way around security. Same-origin policy is keen as hell when dealing with scripting protection, but am I missing something, is it not possible to prevent "surfing" to an execution, at least for certain executables? (edit: after reading some wiki, this is actually called Cross-site Request Forgery! Only decent protection method is to 'update web app code' aka, insert security check.)

I am completely ignorant to how it's done, but since this is (for me anyways) just an issue with passing useful parameters (and allowing Johnny Malicious to change them to whatever he wants), I'm sure the answer lies in how you handle passing information to the server-side. I mean just look at what happens when you click the Save button on an edited post in this forum. An XHR request is made to a server-side php file with two fairly harmless parameters: the action and the post id. How is the new content being sent over! (edit: oh wait a second, looking at Post in firebug there's an additional parameter not passed in the request string called message, and there's my content.. ook, now I want to look more into that..)

(I wonder, could you edit a cached JS file and trick the server into believing this modified file is within the domain and defy same-origin policy?)

I wonder, could you edit a cached JS file and trick the server into believing this modified file is within the domain and defy same-origin policy?

You can trick the server into it because the server doesn't care in pretty much any case. The same-origin policy is controlled by the browser that you're using, so whatever is on the server isn't an issue and doesn't help at all with this. Having said that, no one that's even semi-serious abut trying to hack your system will use a cached script and a browser, they'll be using some other program to send requests.

As has been said here, it is the job of the server to check and verify that the data is coming from a trusted source. This is normally done through sessions, logins, hashs, etc. This is the ONLY way that you will have an even remotely secure application. It's not even that hard to do. All of the server-side languages that I've seen implement some idea of sessions, and if not you can track them yourself. If you want to get really paranoid you can also track IP addresses, user-agent strings, custom-delivered hashs or tokens, and more. The level of security that you have there is dependent on how bad things could go if something does go wrong, but in the real world, it's not hard to keep out the script-kiddies.

Remember, it's up to YOU to enforce the rules, not just sit back and hope that no one finds the security holes that have been left by not building these things in when they should have been there in the first place.

You can trick the server into it because the server doesn't care in pretty much any case. The same-origin policy is controlled by the browser that you're using, so whatever is on the server isn't an issue and doesn't help at all with this. Having said that, no one that's even semi-serious abut trying to hack your system will use a cached script and a browser, they'll be using some other program to send requests.

As has been said here, it is the job of the server to check and verify that the data is coming from a trusted source. This is normally done through sessions, logins, hashs, etc. This is the ONLY way that you will have an even remotely secure application. It's not even that hard to do. All of the server-side languages that I've seen implement some idea of sessions, and if not you can track them yourself. If you want to get really paranoid you can also track IP addresses, user-agent strings, custom-delivered hashs or tokens, and more. The level of security that you have there is dependent on how bad things could go if something does go wrong, but in the real world, it's not hard to keep out the script-kiddies.

Remember, it's up to YOU to enforce the rules, not just sit back and hope that no one finds the security holes that have been left by not building these things in when they should have been there in the first place.

Your post is an invaluable learning experience as well as a kick in the face. Sessions seems like it would be the easy fix if I were not, before deciding on improving my server-side security checks, worried about simple things like request forgery, where the data being passed in is actually coming from a "trusted source" to some extent.

Yeah I should have mentioned server-side session control as well. As stated most server-side languages include session control of come sort, usually implemented as a server-side persistent storage container of some sort keyed with a unique id. This id is stored on the client side in a cookie with no expiry time (so it is valid only for the current browser session) or is passed as a param in GET requests. There is usually also an inactivity timeout on the server-side, so that unused sessions are cleaned up.
These sessions alone prevent most easy forms of attack, but dont make a complete security plan themselves. Anyone that can discover that session id can then perform a man-in-the-middle attack. Of course this group of people includes the legitimate users, so an inside job is still a possibility. Adding additional security like origin checks and such helps here.
But the thing to understand is that security and validation are two separate concepts. Yes they can overlap a bit, but having one does not negate the need to have the other. Just because you think nobody can get access to insert valid data doesnt mean that you can skip adding code to detect it Validation checks would be to prevent sql injection, memory overflows (probably not a real concern with the scripting languages used here though), or if you are running system commands at any point, shell command injection.
It is also very important to remember that no security plan is ever 100% foolproof; you just have to determine what level of security effort is worth it for you app (consider joes personal online address book vs a banking site).