3 ms·

Quick question, how are these files bypassing the authentication before_filter? I mean, a progress.js (Dont know what that is) probably belongs to a project, an

• rst 13y ago
  The attack scenario here is a request from an authorized browser which is run by a hostile page on a different website (e.g., due to phishing attack). And since the request comes from an authorized browser, the cookies typically checked by an authentication before_filter will be present. In detail: 1) the attacker knows of an authorized user, already logged in (most likely). So, any request sent by that browser to the target site will pass authentication checks. 2) they trick that user into loading a web page under their control by some means (e.g., phishing attack). 3) that web page, under their control, includes a <script> tag with a src attribute referencing target .rjs. It loads the target .rjs Javascript into a gimmicked environment in which the private data is captured. Since the web page is under the attacker's control, same-origin rules allow that captured private data to be sent back to the attacker directly. To counter this, the target site needs some way to verify that its own Javascript is making the request, not some hostile web site. Thus the talk of CSRF tokens and checking .xhr?. (The latter counts on the browser's same-origin rules to prevent an AJAX request from the hostile web site --- the same-origin rule blocks that, but in most current browsers, there's no way to prevent the attacker from tossing in a <script> tag.)