If
you need any stronger guarantees about the content of the params object, you need to
use cryptography.
The implications of this are tremendous: every once in a while, some online store
gets in trouble for storing prices as hidden form fields, and not validating them when
an order is placed. Someone with at least a minimal knowledge of HTTPthen
teaches them the ???don??™t trust the client??? lesson by ordering a few plasma TVs for a
dollar each.
Client-side validation
A corollary of these form-processing principles is that validation should always take
place on the server. This is not to discount the importance of client-side validation,
but the application must be designed to be secure, no matter what is sent at the
HTTP level.
134 | Chapter 5: Security
It is perfectly OK to validate data at the client. This is useful because when users
make mistakes filling out a form, client-side validation saves a round-trip to the
server. But if the only thing keeping invalid data out of your application is a piece of
JavaScript, malicious users can simply turn off JavaScript and submit your form.
These two methods of validation represent two different perspectives. Client-side
validation (if any) should emphasize usability, while server-side validation should be
driven by security.
Cookies
In Rails, there is usually no need to deal with raw cookies. The session abstraction
provides a way to store data in a way that looks like a cookie but can be trusted.
Pages:
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208