Hybrid View

  1. #1
    Ext User
    Join Date
    Oct 2007
    Posts
    98
    Vote Rating
    0
    ferr is on a distinguished road

      0  

    Default Cross-site scripting

    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..

  2. #2
    Ext User
    Join Date
    Jul 2007
    Posts
    3,128
    Vote Rating
    0
    devnull has a little shameless behaviour in the past

      0  

    Default


    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.

  3. #3
    Sencha User
    Join Date
    Dec 2007
    Posts
    168
    Vote Rating
    4
    SeaSharp2 is on a distinguished road

      0  

    Default


    Quote Originally Posted by devnull View Post
    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?

  4. #4
    Ext User
    Join Date
    Oct 2007
    Posts
    98
    Vote Rating
    0
    ferr is on a distinguished road

      0  

    Default


    Quote Originally Posted by SeaSharp2 View Post
    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?)

  5. #5
    Sencha User catacaustic's Avatar
    Join Date
    Jul 2007
    Location
    "A Land Down Under"
    Posts
    618
    Vote Rating
    1
    catacaustic is on a distinguished road

      0  

    Default


    Quote Originally Posted by ferr View Post
    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.
    'Once again, fortune vomits on my eiderdown'
    - Edmund Blackadder

  6. #6
    Ext User
    Join Date
    Oct 2007
    Posts
    98
    Vote Rating
    0
    ferr is on a distinguished road

      0  

    Default


    Quote Originally Posted by catacaustic View Post
    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.