Facebook SDK

Thursday, January 2, 2014

Programming Security-Part 5 (Web Development, cont.)


One thing to remember about web apps and input validation is that, if your app accepts comments or other user-supplied content, you need to ensure that your validation scheme strips any HTML or JavaScript before the content is posted to the site. While basic HTML is okay, e.g. text formatting like bold or italics, you need to be wary of links. Cross-site scripting (XSS) attacks can be used by someone posting comment section; anytime a user loads the page, that malicious code will be ran by the browser, making that user, or your site, susceptible to attacks.

While discussed in the context of web development, configuration management applies to nearly any programming task. In this case, you need to ensure your administrator interfaces are locked down, only accessible to authorized admins. Currently, the best authorization method is through certificates, such as smart cards.

Make sure remote access is limited or completely removed. If it is allowed, ensure encryption is enabled and consider using a VPN (virtual private network) due to the information and permissions available to administrators, and the possibility that a privilege escalation attack can occur during a remote session.

Anything that you would consider sensitive, such as passwords, credit card numbers, or even company secrets, should be handled accordingly. Don’t put them on an Internet-accessible server if possible. If you do need to use a sensitive item, e.g. for authentication, don’t use the raw data; store the data separately and generate a hash that will be stored locally, then use the hash for verification. That way the sensitive data won’t be directly accessible.

I remember reading an article about Intel that stated company secrets and other sensitive items could only be printed on colored paper. That way, someone could tell at a glance whether a document was needed to be handled in a special manner. Content management systems can be configured in a similar manner to minimize sensitive material leaks of electronic material.

If necessary, ensure the data is encrypted or hashed, depending on its use. (Hashes are one-way algorithms and can’t be “unhashed” while encrypted data can be decrypted). Don’t maintain sensitive material in a cache or in a persistent cookie; only access it as needed. Once in the cache, it will be in a decrypted format since it has to be available for use. If unencrypted, cookies can be viewed and modified by the end user; if encrypted, it makes it difficult to deal with the encryption key management as keys expire.

Be aware of session management issues. Use HTTPS when possible; Google, Facebook, and other companies are starting to set up HTTPS sessions by default to minimize vulnerabilities and reduce attacks on users. Be sure to protect any authentication cookies you use; if someone hijacks the authentication cookie or otherwise gains access to the session, they can impersonate a legitimate user.

Finally, consider program exceptions when errors occur. Exceptions can provide a lot of information to an attacker, such as the OS being used, the type of web server, database info, or file names. If an error occurs, ensure it is caught internally and not presented to the client; generic error messages can be presented that have a custom error ID for troubleshooting. Exception handling is also important because it can keep the program running even if an exception is thrown, if caught and handled correctly.

No comments: