diff options
author | Sergio <shernade@gmail.com> | 2013-09-16 00:25:00 +0200 |
---|---|---|
committer | Sergio <shernade@gmail.com> | 2013-09-16 00:25:00 +0200 |
commit | edb74a187b905240675317a263d3e8c705157024 (patch) | |
tree | 6280830872873daaf447d5625f96e568edd529fa /guides | |
parent | ebcd9d6c03fecc6946c794c19c544b5f1349b8f1 (diff) | |
download | rails-edb74a187b905240675317a263d3e8c705157024.tar.gz rails-edb74a187b905240675317a263d3e8c705157024.tar.bz2 rails-edb74a187b905240675317a263d3e8c705157024.zip |
incorrect urls
I've found two incorrects urls for adding ':' at the end of the url
Diffstat (limited to 'guides')
-rw-r--r-- | guides/source/security.md | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/guides/source/security.md b/guides/source/security.md index 0c2d3caa4e..7d84681c13 100644 --- a/guides/source/security.md +++ b/guides/source/security.md @@ -290,7 +290,7 @@ NOTE: _Make sure file uploads don't overwrite important files, and process media Many web applications allow users to upload files. _File names, which the user may choose (partly), should always be filtered_ as an attacker could use a malicious file name to overwrite any file on the server. If you store file uploads at /var/www/uploads, and the user enters a file name like "../../../etc/passwd", it may overwrite an important file. Of course, the Ruby interpreter would need the appropriate permissions to do so - one more reason to run web servers, database servers and other programs as a less privileged Unix user. -When filtering user input file names, _don't try to remove malicious parts_. Think of a situation where the web application removes all "../" in a file name and an attacker uses a string such as "....//" - the result will be "../". It is best to use a whitelist approach, which _checks for the validity of a file name with a set of accepted characters_. This is opposed to a blacklist approach which attempts to remove not allowed characters. In case it isn't a valid file name, reject it (or replace not accepted characters), but don't remove them. Here is the file name sanitizer from the [attachment_fu plugin](https://github.com/technoweenie/attachment_fu/tree/master) +When filtering user input file names, _don't try to remove malicious parts_. Think of a situation where the web application removes all "../" in a file name and an attacker uses a string such as "....//" - the result will be "../". It is best to use a whitelist approach, which _checks for the validity of a file name with a set of accepted characters_. This is opposed to a blacklist approach which attempts to remove not allowed characters. In case it isn't a valid file name, reject it (or replace not accepted characters), but don't remove them. Here is the file name sanitizer from the [attachment_fu plugin](https://github.com/technoweenie/attachment_fu/tree/master): ```ruby def sanitize_filename(filename) @@ -447,7 +447,7 @@ Here are some ideas how to hide honeypot fields by JavaScript and/or CSS: The most simple negative CAPTCHA is one hidden honeypot field. On the server side, you will check the value of the field: If it contains any text, it must be a bot. Then, you can either ignore the post or return a positive result, but not saving the post to the database. This way the bot will be satisfied and moves on. You can do this with annoying users, too. -You can find more sophisticated negative CAPTCHAs in Ned Batchelder's [blog post](http://nedbatchelder.com/text/stopbots.html:) +You can find more sophisticated negative CAPTCHAs in Ned Batchelder's [blog post](http://nedbatchelder.com/text/stopbots.html): * Include a field with the current UTC time-stamp in it and check it on the server. If it is too far in the past, or if it is in the future, the form is invalid. * Randomize the field names |