Quantcast
Channel: Hacker News
Viewing all articles
Browse latest Browse all 10943

Egor Homakov: Do not use RJS-like techniques

$
0
0

Comments:"Egor Homakov: Do not use RJS-like techniques"

URL:http://homakov.blogspot.ru/2013/05/do-not-use-rjs-like-techniques.html


RJS (Ruby JavaScript) — a straightforward technique when server side (e.g. Rails app) responds with Javascript code and client-side eval-s it (Writing JS in Ruby is unrelated, I only consider response-evaling concept!)

Here are my usability and security concerns about this interaction.

Possibly other developers use their own RJS-like techniques — they can find my post helpful too.

Broken concept & architecture. This feels as weird as the client-side sending code that is going to be evaled on the server-side... wait... Rails programmers had similar thing for a while :/Any RCEJS technique can be painlessly split into client's listeners and server's data. Escaping user content and putting it into Javascript can be more painful and having more pitfalls then normal HTML escaping. Even :javascript section used to be vulnerable in HAML (</script> breaks .to_json in Rails < 4). There can be more special characters and XSS you should care about. JSONP-like data leaking. If app accepts GET request and responds with Javascript containing private data in it attacker can use fake JS functions to leak data from the response. For example response is:Page.updateData("data")and attacker crafts such page:<script>var Page={updateData:function(leak){ ... }}</script><script src="http://TARGET/get_data.js?params"></script>Voila, joys of RJS UPD as pointed out on HN evaling response will mess with your global namespace and there is no way to jump into closure you created request in..

But I still see in the wild apps responding with private data in javascript. This is a very fragile technique, refactoring will both improve code quality and secureness of your app.


Viewing all articles
Browse latest Browse all 10943

Trending Articles