Ruby on Rails Notes
From Rory.wiki
Contents |
Notes for Testing Rails Apps
scoping
One of the common means for scoping a web. app test is to ask for the number of pages or functions in the application. This tends to be an approximation in terms of the information that you receive from the client. With rails it's possible to get a text file of all the functions and pages within the application, by using the command rake routes. This helps, both in terms of scoping and in terms of ensuring coverage.
discovery & AuthZ
Assuming you're doing a blackbox assessment, rails apps are usually nice and easy to do discovery on, thanks to the REST paradigm. Brute-force discovery for non-linked pages can be valuable, as rails functionality will tend to be predicated on english words (which are usually controller names).
Also once you've got valid base URLs, appending numeric parameters (for listing information) can find valid data, and is a useful test that authroisation is properly implemented.
On top of that issuing (controller)/(id)/edit can again check if it's possible to edit records, even if that option isn't visible.
Another good check to carry out is changing the extension passed. Rails apps will commonly respond_to .xml and sometimes .js requests. If there's any business logic in the respond_to block, requesting another format will bypass it.
XSS
On Rails 3 and above, XSS is unlikely unless the general protection has been disabled. On Rails 2.X and earlier, protection is either by plugin (likely to produce a decent result), or by the developer manually adding escaping to view code (unlikely to get 100% coverage).
