Recently we have been noticing a sharp rise in cybercrime and hacking based attacks, and it has been speculated already that cybercrime will cost the world in excess of $6 trillion annually by 2021. A couple of years ago, IBM’s chairperson – Ms. Ginni Rometty – said “Cybercrime is the greatest threat to every company in the world”. The cyber-attacks tend to be motivated by various factors including money, pride and envy, hence these attacks are amongst the most dangerous attacks of any form.
So what does this mean to you if you own a website? Two of the most obvious applications of websites could be
Definitely website owners never want to risk their data or money, so there comes a need to secure the website they own. Therefore if you own a website, you must secure it as soon as possible, probably just after first few deployments. So here I am going to provide you a basic checklist that you may need work-on to secure your website from basic and obvious attacks.
Disclaimer: Website security is a vast field and this is only a basic list, you may need to tackle more security issues if you want to completely secure your website.
Secure communication channel is one of the most essential things in making a website secure. Most of the websites around the world are moving towards secure media for communication, and HTTPS (since websites are hosted over the HyperText Transfer Protocol) is one of the most secure mediums yet. For further reading, see “What does ‘https’ mean, and why is it necessary?”.
There are 3 well known major kinds of hosting environments viz. In-house hosting, Subcontractor based hosting and Cloud based hosting. All of these have their pros and cons, which results in trade-offs when choosing the hosting environment for your website.
However if you choose any of these, you should make sure that the environment is properly protected. You should ensure that the environment is behind a firewall at-least and no unauthorized user can access anything other than the website on hosting environment by any means. For further reading, see this “Web Hosting Service”.
IIS, Apache, Nginx, Tomcat, e.t.c… No matter which web-server you are using to host your production website, you should make sure that it is properly configured. By proper configuration I mean to say that for example, if your website does not support uploading of files then the web-server should reject any of such requests before the execution cycle starts.
Another example would be disabling the directory listing (and whitelisting directories that need directory listing, if any but not preferred) because an attacker can extract significant information about your website if directory listing is enabled.
Another dimension in this area is creating a less privileged Operating System user designated to run the Web Server, this ensures limited access to the website over the hosting environment, resulting in better protection of web server. Similarly there are many areas to consider, for further reading you may see this Microsoft Developer Network’s article or these Apache’s Security tips.
This is one of the most essential areas that you may need to work on. A website is usually composed of many libraries from different vendors and many applications (Web-Server, DBMS, etc) from different organizations. Similarly different websites are hosted on different versions of Operating Systems.
There is a general rule, that every software contains bugs, however often newer versions of a software contains fixes to those bugs. You should list all the software involved in your Website and keep track of the stable updates, if the updates contain sizable security and/or performance fixes, then you should plan to acquire updates soon.
If your website uses any kind of database, be it RDMS, NoSQL, Graph Database, File based or any other, securing it should be in your primary checklist. It is a better practice to keep database not on the same server where the website is hosted. This practice has many benefits like allowing scalability and added security.
So if the database is installed on a machine other than the web server, then it should be ensured that this database is not publicly accessible and only the web-server can access it. If it is possible to use a less privileged user to connect to the database, given that all the functionalities of the website are possible, then you should use it straight away. Another dimension is encrypting the sensitive information (e.g. passwords) within the database, so that any leaked access to database may not compromise the sensitive data.
This is again related to databases, if you have a SQL based database, then this may be one of the greatest threats your website and database may have. Malicious hackers use this as a primary step to propagate their queries to the database.
By definition, the SQL Injection is a method where SQL queries are provided in any input to the website (which reaches the database), so that the provided queries may get executed against the database. Using this, for the worst case, an attacker can destroy all the data in your database. You should avoid this by disallowing or encoding any SQL like syntax in the input before it is executed against the database. For further reading, see this SQL Injection Prevention Cheat Sheet.
Validations are very necessary to ensure the integrity of the data in the database, this disallows any attacker to write an automated script with the intention of creating enormous amount of invalid data in the database.
Also sometimes it is possible if your website is not properly tested over the input data, that a bad input or a sequence of invalid inputs my break your website. Avoiding these problems would require healthy input validations (but be cautious that unnecessary validations annoy users, may result in bad User Experience, so you should handle it smartly). For further reading, see this Mozilla Developer Network’s article.
Similar to input validations, you may need to validate the user access to your website, as often automated scripts or software based robots try to penetrate random websites, and if there is no validation over who is accessing the website and how frequently, then it may compromise the integrity of the overall website, either in terms of data or the website may get hacked if the attacking script/bot is lucky.
One of the well acknowledged method for validating user access is using a captcha, it serves for both input validations and user validations. A captcha is a computer generated image that is easier to understand for humans but almost impossible for the software bots. This again is a vast subject, you may like to see this Microsoft Developer Network’s article.
Well, if you are using a Content Management System (CMS for short), e.g. Drupal, WordPress, DotNetNuke, or any other CMS, what you need to know is that the source code of a CMS is accessible to everyone, and to the attackers as well. The attackers know how different CMS’ work and how to tweak a CMS in a way to either attack or hack the data.
So what you should do is to change the default settings of the CMS, e.g. if it is known that the website content for a CMS resides in protected folder, or the names of entities in database have some prefix or suffix, e.t.c, then you should change these values.
Internal information may refer to many things, e.g. not to expose the version and brand of your Web Server, not to expose the version of host Operating System or any other sensitive information. This is one of the most underestimated and understated areas in Website Security, but I feel that this is one of the most crucial ones.
For example, a .php somewhere in the URI may indicate that the language you are using is PHP, which may allow an attacker to understand or guess the underlying architecture of the website. To avoid this, you may need to configure your Web Server not to return any of such file extensions that hint the underlying architecture of the system. Similarly, the admin pages of a website, if they are not intended for everybody to access, then the access to such pages should be whitelisted.
Other than these, an area I would like to mention here is that often we see URIs like https://xyz.abc.com/users/1, where it is very easy to know that we are accessing a user whose ID is 1. This ID may refer to the identifiers in the database, so the problem with this is the easy guessing of identifier of any other user, a good use-case would be a review or a payroll system where these identifiers may matter a lot.
Therefore by any means, if an attacker is successful in even partially propagating the system, these identifiers may allow him/her to make most of the attack. So if it is easy to encrypt such sensitive information in URIs and is not affecting the overall performance, then you should prefer encryption.
One last thing I would like to mention here is that if you are allowing user to see the logs that the website or a particular process has written, then you should never write any logs that can expose the implementation level, system level or the architecture level information. This will not only create a threat to the website but may be used by the competitors to create a system extending on your website’s architecture.
One thing that I would mention here is that usually Web Servers have default error pages, which are displayed on fatal errors or on HTTP errors like 404 ‘Not Found’ error. This possesses a potential threat of exposing some of the most raw information to an attacker and therefore must be replaced by customized error pages with translated error messages.
Same goes for any of the error messages or system level messages conveyed to the user, either over API or displayed on website, if these contain any internal information, then this may serve as a great threat to the overall website.
Passwords, they always do have a risk to be guessed or generated randomly by an attacker. So a strong password means that the attacker may not be able to access the resources he/she is trying to reach. The resources may be the admin pages, API keys or any other critical resource.
So a carefully thought password, which contains a combination from different kinds of characters (numbers, alphabets, symbols, e.t.c.) and is long enough so that it cannot be generated randomly, should be used. If using ssh keys can be replaced by passwords, then it is very much preferred to use the ssh keys instead of passwords.
Cross-Site Request Forgery (CSRF) is an assault that powers an end user to execute undesirable activities on a website in which they are currently authorized. CSRF assaults particularly target state-changing requests, not burglary of information, since the attacker has no real way to see the response to the forged request.
With some help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a website into executing actions of the attacker’s choosing. You should be able to protect your website from CSRF so that any of such actions are disallowed. For further reading, see this Open Web Application Security Project’s article.
Similarly for Cross-Site Scripting (XSS), I would quote Wikipedia here, that “XSS is a type of computer security vulnerability usually found in websites. XSS enables malicious hackers to inject client-side scripts into web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy.”
This is one of the most commonly used and an acknowledged threat to any website. You can have a further reading at this Wikipedia Article which I have quoted.
Often websites write cookies within the end-user’s browser to store the authentication information, the end-user can be tricked by an attacker to expose his/her cookie information. Infact Community Emergency Response Team (CERT) has issued warnings that cookies can be compromised by attackers and can create an active threat. Furthermore, one of the kinds of attacks based on cookies can be what is stated on the CERT’s website
“A cookie can contain a “secure” flag, indicating that it should be only sent over an HTTPS connection. Yet there is no corresponding flag to indicate how a cookie was set: attackers who act as a man-in-the-middle even temporarily on an HTTP session can inject cookies which will be attached to subsequent HTTPS connections.”
So it is advisable to be very careful with cookies, avoid where possible or otherwise ensure proper security measures, as specified in this CERT’s directive.
If your website is based on an HTTP API or additionally exposes an HTTP API, you should be careful with the authentication mechanisms (if it supports authentication) and accessibility. Better is to follow the REST APIs instead of simple HTTP APIs, as it allows general classification of methods regarding which method is good for what.
Based on this information, access can be allowed or blocked to particular set of users, e.g. if a user has permissions to only retrieve and update an entity but not to delete it, it may be safe to filter the delete method from the request for this user. Similarly you should vary access based on the content-types of HTTP APIs, and allow or block some of the content-types based on the need.
There are well acknowledged access control protocols for HTTP APIs, most popular methods are Basic and Digest Authentication, OAuth 2.0 and OpenID Connect. These access control protocols rely on a security token being passed from client to server with a REST call. Clients obtain a security token from a Security Token Service, or STS for short. OAuth 2.0 and OpenID Connect authorization server is an example of an STS. You should make sure that a proper and well acknowledged protocol is in-place in your HTTP API.
Furthermore, the session authentications must be based on some authentication/session tokens, that expire after some time and require re-authentication or generating a new token without expiring the session. This way if an end-user’s authentication token has been stolen by some malicious attacker, he/she cannot use it for a longer duration.
One thing that must be ensured is disabling the cross-origin requests, and allow only whitelisted domains if required. Also API rate limits should be implemented, this is to reduce massive API requests that cause denial of services and also to mitigate potential brute-force attacks or other misuses of services.
Further reading on this topic can be accessed on this OWASP’s “REST Security Cheat Sheet” article.
Last but not the least, there is an old saying, “Backup! backup! Backup!”. This signifies how important is it to have properly scheduled backups of the production environment of your website. Not only this ensures a recovery plan for if you have a bad day and your website gets hacked, but it also ensures safeguarding and recovering from fatal errors, crashes and other fatal mishaps. So what you should do is to take a backup of the data you value in your website at-least twice a week, if not daily, and store the backup on a machine other than your hosting machine or the database machine.
That’s all for now, this was a basic checklist that you should at-least make sure that you have if you are planning to develop a secure website. I have tried to be concise but this field of web-security is so vast that it cannot be easily summarized in few pages, and separate articles can be written for each sub-topic.
USA408 365 4638
1301 Shoreway Road, Suite 160,
Belmont, CA 94002
Whether you are a large enterprise looking to augment your teams with experts resources or an SME looking to scale your business or a startup looking to build something.
We are your digital growth partner.
Tel:
+1 408 365 4638
Support:
+1 (408) 512 1812
COMMENTS ()
Tweet