A transactional website that is open to everyone, should be able to protect its assets against malicious intents. An insecure website has the potential to compromise the user data on one hand and on the other, its services can be disrupted, both of which will result in loss of business. There are industry standards for security that must be adhered too. These are time tested methodologies and protocols that should be incorporated in the design in order to provide services and functions on the world wide web. We will look at some of the security standards and good practices in this blog. In the later part of the blog, we will look at methodologies to test and certify if your website can ward of threats emanating from external and internal actors.
We will start with something very trivial i.e. the domain name URL of your hosted service. For one, you should enable encryption on your domain and forward any of non-HTTP requests to HTTPS. If you are using apache for serving the URLs this can be configured using REWRITE module. Use of HTTPS ensures data passes securely over Internet.
Another issue that everyone faces while hosting is whether you should be using "www" before your domain or not. If your server is serving both the URLs with "www" and without then it will confuse the crawlers who will end up indexing your content twice, probably resulting in a lower rating of your content. REWRITE module comes in hand here too if you are running apache. In case you are using hosted services probably this is already configured properly and you can move on.
The transactional elements of your website should be password protected. There are straightforward ways to validate complex enough passwords that are not easy to hack. Given the complexities of web applications where they have to interact with third-party services, maintain session info etc there are industry-standard authentication schemes like OAuth. Password should be stored using one-way hash SHA-256(or other strong one way encryption) in DB. OAuth 2.0 focuses on client simplicity while providing specific authorization flows for web applications, desktop applications, mobile phones, and living room devices. For websites, that deal with money or critical user information, should secure their website using 2-factor authentication, ie by validating the user email or phone number using OTPs. Two-factor authentication (2FA) is a security process that increases the likelihood that a person is who they say they are. The process requests users to provide two different authentication factors before they can to access an application or system, rather than simply their username and password.
Authorization is the mechanism by which a system determines what level of access a particular authenticated user should have to secured resources controlled by the system.
- The first line of defence is to secure the file system. The various files and directories should be given appropriate permissions so that the webserver and other software that you are running have the appropriate access. This creates a sandbox for all the users of your system that access it via the web for example.
- The second line of defence is to secure the network. This means the ability of black listing malicious ips, preventing DDoS attacks and getting easy access to ports running critical services. If you are hosting on the cloud, like many of us do these days, then you need to setup firewall and access policies.
- The application-level design should permit role-based access to the services and data. The design should be flexible enough to be able to assign various roles to a user. The roles to resource mapping and user to roles mapping can be contained in policy files or database tables.
- CSRF(cross-site request forgery ), is an attack that tricks an end user to execute unwanted actions on a web application in which they’re currently authenticated. A CSRF can be engineered by sending a link in email or on social media. A user can thus be tricked to change the state of his account or much worse like transferring funds. If the victim is an administrative account, CSRF can compromise the entire web application. The Open Web Application Security Project® (OWASP) provides tools to find and mitigate such dangers.
XSS and Misc Vulnerabilities
Cross-site scripting (XSS) is a type of security vulnerability typically found in web applications.
XSS attacks enable attackers 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.
XSS effects vary in range from a petty nuisance to significant security risk, depending on the sensitivity of the data handled by the vulnerable site
and the nature of any security mitigation implemented by the site's owner network. Many such vulnerabilities can be found out by automated penetration testing
like the one provided by OWASP ZAP security tool. The OWASP ZAP security tool is a proxy that performs penetration testing against your live application at runtime.
It’s a popular (over 4k stars) free, open-source project that is hosted on GitHub.
Figures showing a penetration test and report.
Several online tools that can also assist in scanning various aspects of your website. Like shown in following screenshots, especially scans the headers that are part of the HTTP protocol.
Backdoors in third party software
Most of the software that you develop in general depends on many third-party packages. These packages provide functionalities for data access, connection pooling, logging, networking tools and the like. These are prone to defects too, any vulnerabilities found on such open-source packages are published regularly as CVEs. You need to be aware of such vulnerabilities and review these in case some of them can affect the security of your product. It is part automated and part manual process.
The Snyk tool can automatically detect known CVEs in your dependencies and categorize them in terms of the harm they can cause. It is your responsibility to update to the version that fixes such exposures.
Figure showing Snynk
A backend database is part of most of the web applications. It could be relational-data stored in a database like MySql or unstructured data being dumped into a NoSql database like MongoDB. Some of this data is critical information, like passwords to access third party services like email server, object stores etc. This critical information should be available on only need to know basis. Programmers and maintainers have easy access to such information and therefore this data should be encrypted. All industry-standard database provides such encryption. Moreover, TLS(transport layer security) should be configured to protect such data when in transit. Read the documentation for the database that you use and configure it accordingly.
The blog is an attemp to look at various threats that can effect your web application and result in loss of business. It is important that you get your web property cetified safe against such dangers.