Advanced Rails - Building Industrial-Strength Web Apps in Record Time

Application Issues | 135

def show

@message = Message.find_by_user_id_and_id(current_user.id,

params[:id])

end

This automatically gives you protection against users viewing messages they don’t
own, by raising aRecordNotFound exception.

Secure Fallback

Now that many Rails applications incorporate some amount of AJAX, fallback is an
important concern. Depending on your users’ needs, eithergraceful degradation
(starting with a full-featured site, then testing and fixing for older browsers) or
progressive enhancement (starting with minimal features and adding features for
newer browsers) may be the catch phrase. In either case, developing for older brows-
ers involvesfallback, or using a less-preferred option when the preferred option fails.
It is important that fallback is secure—otherwise, attackers could force the applica-
tion into fallback mode in order to subvert its weaknesses.

A typical example of fallback on the Web is using a regular form post when a Java-
Script form post fails:

<form action="/standard_non_ajax_action"

onsubmit="do_ajax_submit( ); return false;">

...

</form>

When the user has JavaScript enabled, thedo_ajax_submit()function is called and the
standard form post is canceled. Typically, that function will serialize the parameters,
send them to the server, and perform some other action. With Rails’respond_to
methods, you can actually use the same actions for both standard HTML and Java-
Script responses, differentiated by the HTTPAccept header.

There is no specific security guidance here, except to review your code and be sure
that an attacker cannot bypass your security by using your non-AJAX methods rather
than your AJAX ones. Typically, the AJAX methods are the flashiest, best sup-
ported, and best tested. They get the most attention, but it is just as important to pay
attention to the non-AJAX interfaces.

Avoid Security Through Obscurity

One principle of security is that security through obscurity is no security at all. Secu-
rity should be inherent in the system, and not depend on an attacker’s ignorance of
architecture. This descends from Kerckhoffs’ principle in cryptography: a system’s
security should lie only in its key (rather than in the algorithm). This principle can be
paraphrased for web applications: your application should be designed so as to
remain secure even if your source code, architecture, and configuration (with the
obvious exception of passwords and the like) were published for all to see.