Rails Security Guide "three"

Four redirects and files

Another type of security problem is the redirection and use of files around Web applications.

4.1 redirect

Redirection in Web applications is an undervalued Craker tool: It can not only allow users to fall into a Web site, but also create a complete attack.

When a user is allowed to redirect by a URL, it may be a vulnerability. The most obvious attack is to redirect the user to a fake page that looks exactly the same as the original page. This so-called ' phishing attack ' is to inject a malicious link into a Web application via XSS or to put a link to a bogus web site (where the domain looks similar and the page is the same) by sending a user an email containing a normal, unsuspecting link. It is no doubt, because the URL of this link is the normal Web application, the URL to the malicious site is hidden in the redirect parameters: http://www.example.com/site/redirect?to= Www.attacker.com. Here is an example:

def legacy
　　 redirect_to(params.update(:action=>'main'))
end

If the user accesses the legacy action, it will be redirected to the mail action. The intention is to maintain the legacy parameters and pass these parameters to the main action. However, if it contains a host key, it will be exploited by the attacker.

Http://www.example.com/site/legacy?param1=xy&param2=23&host=www.attacker.com

If it's at the end of the URL, it will be hard to notice, and the user will be redirected to the attacker's page unnoticed. A simple solution is to include only the expected parameters in the legacy action (whitelist), not all parameters that are not intended to be canceled. If you redirect to a URL, you need to check it with a white list or regular expression.

4.1.1 Self-contained XSS (self-contained XSS attack)

Another redirect and self-contained XSS attack is a data protocol used in Firefox and opera. The protocol directly displays its contents in the browser, allowing any content from html,javascript to the picture. (This is not a vulnerability, but a feature)

data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K

This example is a BASE64 encoded JavaScript that displays a simple message box. In a redirected URL, an attacker can redirect the URL with malicious code inside it.

The more detailed attack principle can be see here: http://www.gnucitizen.org/blog/self-contained-xss-attacks/

Countermeasures: Do not allow the URL of the "supply" (parts of) to is redirected to. (Honestly, I don't see it here)

4.2 File Upload

-Ensure that files are not overwritten with important files and synchronized media file processes last time.

Many Web applications allow users to upload files, and the file names that users can choose should be filtered at any time because an attacker can overwrite any file on the server with a malicious filename. If you store uploaded files in/var/www/uploads, the user enters a filename: ... /.. /.. /ETC/PASSWD, it may overwrite an important file.

Do not attempt to delete a malicious part when filtering the file name entered by the user. Think about it, if you remove all the. /, attacker input. .. , then the result becomes. /。 It is best to use a whitelist to check the validity of file names with an acceptable set of characters. Once it is not a valid filename, reject it (or replace it), but do not delete them. Here's a list of file names from the Attachment_fu plugin:

def sanitize_filename (filename)
    Returning Filename.strip do |name|
        # NOTE:File.basename doesn ' t work right with 

Windows paths on Unix
        # get only the filename, not the whole path
        name.gsub! /^.*(\\|\/)/, 

''
        # Finally, replace all non alphanumeric, underscore
        # or periods with underscore
        

name.gsub! /[^\w\.\-]/, ' _ '
    End
End