Introduction

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 the 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 to. These are time-tested methodologies and protocols that should be incorporated in the design to provide services and functions on the world wide web. We will look at some of the security standards and acceptable 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.

Domain URL

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 non-HTTP requests to HTTPS. If you are using apache for serving the URLs, then configure it using REWRITE module. The use of HTTPS ensures data passes securely over the 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 them, 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 correctly, and you can move on. REWRITE module comes in hand here too if you are running apache. In case you are using hosted services probably this is already configured correctly, and you can move on.

Security Standards

Authentication

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 one-way strong 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 accessing an application or system, rather than merely their username and password.

Authorization

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 defense is to secure the file system. The various files and directories should be given appropriate permissions so that the software you are running has the proper access. The right file permissions effectively create a sandbox for all the users of your system that access it via the web, for example.
• The second line of defense is to secure the network. This means the ability to blacklisting 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, 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 specific roles to a user. Mapping is, in general, used to map roles to resource and user to roles.
• CSRF(cross-site request forgery ) is an attack that tricks an end-user into executing unwanted actions on a web application in which they're currently authenticated. A CSRF is engineered by sending a link in email or on social media. Thus, a user can be tricked to change his account's state or, much worse, trick him into 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. Attackers may use a cross-site scripting vulnerability to bypass access controls such as the same-origin policy. XSS effects vary in range from a petty nuisance to a significant security risk, depending on the sensitivity of the vulnerable site's data 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 the 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 hosted on GitHub.

Figures showing a penetration test and report.

Several online tools can also assist in scanning various aspects of your website. As shown in the following screenshots, it 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 according to the harm they can cause. It is your responsibility to update to the version that fixes such exposures.

Figure showing Snynk

Secure Database

A backend database is part of most 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 servers, object stores, etc. This vital 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. Please read the documentation for the database that you use and configure it accordingly.

The blog attempts to look at various threats that can affect your web application and result in loss of business. It would be best if you get the web property certified safe against such dangers.