Peter De Berdt said the following on 06/01/08 06:08 PM:
This kind of scanning is a common 'pre-attack' scan used by malicious
1. If you don't want it to be seen, it should have been in a password
protected part of your site. Never trust user input, whether it's in
forms or in urls.
Post.find( .... params[:post] ...)
is high risk.
Always sanitise and filter your inputs.
The example given in AWDWR about cross-site-scripting is just the
2. If you want to avoid record scraping for data within the pages, use
different techniques like clientside decrypting of encrypted elements or
use rmagick to render the data as an image instead of a string.
Just as a generation of spammers did to try and get around SpamAssassin.
(Only it didn't work.)
3. If you want to avoid record scraping of entire pages over your
complete database or brute force attacks, use log file analyzers that
reconfigure your firewall to ban those ips when certain conditions are
met. fail2ban is such a solution.
Log file analysis and IDS/IPS are an essential part of a security strategy.
4. If you want to avoid hotlinking to files, use Apache/other webserver
techniques to avoid it.
Again, well documented.
5. If you need to make temporary file downloads with a hash in the url,
use a simple named route instead of shoving it in a RESTful route.
And yes, lots of sites use temporary URL strings with limited lifetimes.
Its no different from fixed lifetime values in the cookies.
Believe me, this kind of scraping is the thing you need to worry about
... until you get bitten.
The cost of retrofitting security after an incident is always going to
be greater than the cost of addressing the risks when designing the
system. You don't always have to load up the complete suite of security
tools from the start, but do think about it.
Sometimes small architectural changes that don't really affect the code
development can make a big positive or negative impact on security.
Sometimes it IS coding style.
For example, I list the real actions in controllers with 'public ....'
and use 'hide_action'.
But then I'm a bit paranoid. (Actually I'm paid to be paranoid.)
There is a great deal of information on secure programming style and
considerations. Some is language specific and some is perfectly
general. Some that seems specific because of the examples is actually
quite general. (injection attacks, XSS, print format string hijacking ...)
Consider also that the term 'security' means more than keeping hackers
and attacks out. You may have a requirement for availability and for
protecting PII or maintaining integrity of records. To say nothing of
'resilience and robustness', for example ensuring availability to
legitimate users in the faces of DoS attack.
See also http://rubythis.blogspot.com/2006/11/rails-security-checklist.html
Rubyists can always learn from Perl - one way or another