开发者

Is JSON.parse() really safer than eval() when web page and ajax call come from same server?

开发者 https://www.devze.com 2023-03-21 23:25 出处:网络
I get that JSON.parse() prevents an attacker from injecting javascript into the response since a JSON parser is just a text parser, not a script parser so please don\'t close this is a dup of all the

I get that JSON.parse() prevents an attacker from injecting javascript into the response since a JSON parser is just a text parser, not a script parser so please don't close this is a dup of all the other questions that talk about that. This is a different question.

If an attacker can hijaack your Ajax call and put javascript into the Ajax call aren't they just as likely to be able to hijack your actual webpage and put arbitrary javascript into your page from which they could accomplish the exact same a开发者_JAVA技巧ttack?

Sure, you have nothing to lose by using JSON.parse() instead of eval() (unless you don't have a JSON parser yet in your environment and have to add more code to get one), but what situations does it really add safety if your web page is being served by the same host as your ajax call?


Yes, it is really safer. Every precaution you do not take is a set of potential exploits you don't prevent.

An attacker might be able to have some control over your server's output without being able to change it entirely. Nobody's suggesting it's a magic bullet, but it's potentially faster and you're not creating a potential vulnerability that could come back and hurt you.

Maybe someone running your server is having a bad day, and does something silly like constructing JSON by concatenating unsanitized user input:

<?php
    print '{"foo": ' . $_GET['bar'] . '}';
?>

If you're using JSON.parse, the worst they can do is shove a large object into your memory. If you're using eval they can hijack everything.


Well, if they're able to inject into your AJAX responses they've probably already successfully man-in-the-middle'd you in one way or another (ARP, DNS or something else).

See http://en.wikipedia.org/wiki/Man-in-the-middle_attack for more details on these types of attack.

You are correct in that, if they can inject into your AJAX response, they can inject whole pages as well. Really, anything you receive OR send via networking is now vulnerable in a MitM unless something like HTTPS\SSL is being used.


That is a very good point. The only thing I can think of is that JSON.parse would have opportunity to be faster than eval.

A much less likely advantage is if the browser already has the HTML/JavaScript cached and the server uses Cache-Control to say that it does not need to reload. If that happens then of course a person intercepting would not have a chance to modify the page. But that is a very rare set of circumstances. Chances are, you are going to require the browser to check for a newer version of the HTML/JavaScript which is the default behavior.

As for the security difference, I think you are correct.

As for myself, I work with HTTPS confirmed systems only. But I have a function that uses JSON.parse if available and falls back on eval just for the speed improvement.


Well... I'm not advocating the usage of eval, but I don't think it constitutes a security issue in Javascript, because Javascript is client-side language. If you don't use eval in your code, what prevents me from running javascript:my_own_evil_code() in console or address bar? It is Javascript, I can run my own code or modify yours, create my own HTTP requests and do anything with HTTP responses, or even add my own eval to your functions.

You shouldn't use eval if there is another comparable solution available, but if you, just for simplicity, want to do eval('('+jsonstring+')') to emulate JSON.parse, I don't think it is a big mistake.

0

精彩评论

暂无评论...
验证码 换一张
取 消