Prev | Current Page 200 | Next

Brad Ediger

"Advanced Rails"


136 | Chapter 5: Security
This is not to say that you should publish your routes and system architecture; there
is no need to aid an attacker. Defense in depth (having multiple redundant layers of
security) is an important principle as well. But the guiding principle is never to rely
on secrecy for security.
Secure Your Error Messages
Error messages can reveal a lot about the configuration of your servers. Even the default
Apache error messages may reveal semi-sensitive information through the server signature
line:
Apache/1.3.36 Server at www.example.com Port 80
You don??™t necessarily want to volunteer this information to a potential attacker. In
addition, the HTTP Server header often contains more detailed information, including
a list of all server modules that are installed and their versions. You can reduce
this information to a minimum with two lines of Apache configuration. Put these at
the top level of the Apache configuration file:
ServerSignature Off
ServerTokens Prod
In Rails, you can also inadvertently expose stack traces and source code on error if
you don??™t ensure that Rails knows which requests are ???local.??? By default, in development
mode, the ActionController::Base.consider_all_requests_local configuration
attribute is set to true. This means that every uncaught exception will show a
stack trace (with source code), regardless of the source IPaddress.


Pages:
188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212