6

Ok, so today I had very good experience on my builded systems. Some guy "hacked" everything and said it was an ajax issue. This is what he said to me:

you are relying on AJAX
when I have access to user's browser I have access to all AJAX functions you wrote for him so I can do anything written in your javascript pretending to be that user

and this is absolutely hillarious - how could someone access to user scripts via ajax? Also I'm using node on server but can't realize where the problem is.. the example of ajax:

var transfer_data = {
                id: jQuery(this).data('spin-id')
            };

jQuery.ajax({
            url: init_s.forms.provably.callback,
            type: 'POST',
            dataType: 'JSON',
            data: transfer_data,
            success: function (data) {
                console.log(data);
                if (data.type == 'failed') {
                    jQuery('#check_modal').modal('toggle');
                } else {
                   // add data
                }
            }, error: function (e) {
                console.log(e.message);
            }
        });

and the example of running node script:

socket.on('new_spin_entry', function (data) { ... });
socket.emit('new_spin_entry', {
                            entry_id: data.user_spin_data.id
                        });

so what the heck is this? how this is even possible?

P.S. I forgot to mention that he inserted alert in my script that was loaded in page. Not the server scripts, but scripts that was loaded to user

P.P.S.: this is what I'm able to see in console ATM system was down: enter image description here

Arnas Pečelis
  • 1,000
  • 2
  • 12
  • 32
  • And what is your architecture for authenticating request to the node server? – codebased Nov 06 '15 at 22:06
  • If he can add an alert to the user, than means there is an XSS vulnerability which is a bad thing. – epascarello Nov 06 '15 at 22:06
  • he inserted alert in javascript file that was loaded with DOM. – Arnas Pečelis Nov 06 '15 at 22:10
  • 2
    I don't see the issue. If someone has control of the user's browser, he can do anything that user can do. The security problem is whatever exploit he used to take control of the browser, it's not a problem with your code. – Barmar Nov 06 '15 at 22:10
  • @Barmar can you extend your answer? how to avoid such a problems? – Arnas Pečelis Nov 06 '15 at 22:16
  • 1
    What problem are you trying to avoid? If a hacker has control of a user's computer, they ARE that user as far as you're concerned. – Barmar Nov 06 '15 at 22:18
  • im trying to avoid attack via ajax that contains control of users computer. Im not really sure what you want to say, but im 100% sure that he was not able to control my browser. I think that some scripts was sended after node response or something.. – Arnas Pečelis Nov 06 '15 at 22:24

2 Answers2

6

If someone has complete access to a browser, then they can run any code they like in it - including modifying or adding JavaScript to your pages. That has absolutely nothing to do with a site using Ajax though — any point where the client interacts with the server may be vulnerable.

If they can only alter the page for the browser they are using themselves, then that is normal behaviour and nothing to worry about.

If they can inject data via a link or form submission from another site, then you are vulnerable to reflected XSS attacks.

If they can inject data that is saved somewhere on your server that causes a script to run for other users then you are vulnerable to stored XSS attacks.

If they can only do this if they are an authorised user, then you need to restrict / properly encode submitted data (since your authorised users can't be trusted).

If they can do this by having an authorised user visit a page hosted elsewhere, then you are vulnerable to CSRF attacks and you need to implement protection against them (nonces are the usual solution).

See also:

Community
  • 1
  • 1
Quentin
  • 914,110
  • 126
  • 1,211
  • 1,335
3

Any variables being sent on the client side can be modified by a hacker before these are sent to your server which handles the request. To prevent this you must use validation on the server side code handling the data being received. Never trust any form of user input or variables received directly from the client that can be manipulated . So for example in this case you could use session variables to validate that the transfer details actually refer to the logged in user, and also check that these do not contain some malicious code such as sql queries designed to exploit security flaws in your code.

Hope this helps!

numX
  • 830
  • 7
  • 24
  • If the hacker has control of the user's browser, then he's he has the user's session cookie. – Barmar Nov 06 '15 at 22:11
  • However, session state variables may be kept server side in which case they cannot be modified through the client eg: http://stackoverflow.com/questions/13451543/how-safe-is-it-to-use-session-variables-asp-net-c-sharp – numX Nov 06 '15 at 22:14
  • about filtering inputs - they are being filtered on code when receiving, becouse I'm using laravel as well. About session variables - are you talking about "Cross Site Request Forgery"? – Arnas Pečelis Nov 06 '15 at 22:14
  • 2
    @numX I understand that. But how will this "validate that the transfer details refer to the logged in user"? Since the details will come from the logged-in user's browser, it will validate correctly. – Barmar Nov 06 '15 at 22:17
  • For example on login you can set a server side session state variable to store the current user - this will not be accessible through the client. Once the AJAX request is received by the server , the 'user' session variable can be used to determine whether the transfer details received are a legitimate request made by the user, or possibly a malicious attack if the data relates to other users. – numX Nov 06 '15 at 22:17
  • 1
    But surely if the browser has been hijacked, whatever session data you have on the legitimate user is irrelevant, because it will be exactly the same as the hacker. It'll be the same user-agent, the same IP, the same session - everything's the same. Whatever the legitimate user can do whilst logged in, the hacker can do just the same. – TheCarver Nov 06 '15 at 22:29