How to secure a Web application to avoid hacking? Here are the top most common security risks for a web application that a developer should be awared of.
1. Cross-site Scripting
Social network and public forum application usually re-post a user post to other readers. When the application display a user post without sanitize the data, a hacker can enter harmful JavaScript in the page. The JavaScript code will be executed when readers read the page. The script can steal a user session cookies, redirect a user to a look-a-like-site, or stealing data etc ... Always sanitize user entered data and reject the request for suspicious text.
2. Session fixation
A hacker obtains a valid session cookie for a particular web site by visiting a web page in the site . The hacker may post a JavaScript in the web site which replace a visitor cookie with this new session cookie. When a user view the infested page, the session cookie will be therefore replaced. The user may be fooled to login again which the hacker can access the account from another machine using the same session cookie. Web developer needs to sanitize a user post to strip out JavaScript before re-display the text.
3. SQL Injection
When a user entered form field data is not sanitized and use it directly inside a SQL statement, a hacker can intentionally change the original meaning of the SQL and have un-authorized DB operations. e.g. SELECT * FROM users WHERE login = 'john' AND password = '' OR '1'='1' LIMIT 1 will return a valid user if a hacker enter the password as ' ' OR '1'='1'. Web developer should use prepared statement in executing a SQL statement.
4. Cross-Site Request Forgery
A user first login to a very popular site say bank.com. When the user later visits another site B, a hacker can post image tag code like <img href="www.bank.com/transfer_fund/> into an infested web page. The user browser will invoke the image URL with the user session cookie for bank.com. Since the user is already login to bank.com, a hacker may issue request (/transfer_fund) to bank.com without the user awareness. Web developer needs to sanitize user post and/or generate a secret token in the request to prevent forgery request from other site.
5. File Upload/Download
If an application takes a user entered filename to read or store a file, a hacker can enter filename like ../../../etc/passwd to read or overwrite sensitive files. Always sanitize user provided file location and do not save a file with the name provided by a user. Also sanitize the file extension used in the upload file.
6. CSS/Header/Ajax Injection
Similar to XSS hacking but apply to CSS, HTTP header or Ajax. Always sanitize use input data.
7. URL Redirection
When a web site provides a URL links that take a parameter for host redirection, a phishing link can be created by a hacker (distributed by email, XSS or external links) to redirect a user to a look-a-like-site. Do not provide a redirect link that take URL address directly. Verify with an internal white list before any redirection.
8. Brute-forcing accounts password guessing
Enforce stronger password and do not disclose whether a user account exist (in particular in the forget password feature). Any changes in email or password should require user to re-type the old password.
9. Sniff session cookie in an insecure network
A user log into a web site using a public and non-secure network, say a coffee shop Wi-Fi connection. A hacker can monitor the traffic and capture the session cookie. The hacker can make request to the web site using the session cookie as if (s)he is already login as that user. Use HTTPS in accessing those web site if available.
10. Don’t clear out the cookies in a public machine
Logout from a Web Site after using a public machine. Do not use the remember me feature for auto-login in a public machine
No comments:
Post a Comment