Web service security — common requirements

Sometimes we need to develop security requirements for some abstract web application. Yeah, unfortunately, we don’t always know the whole feature request list in advance. Web designers prefer to work according to a waterfall model, but it may not always be possible. A technically skilled client is a rare case. It means the final result can be far away from the original idea.

What should a security specialist do in this situation? How to outline security requirements for web application which can quickly grow from landing page to marketplace? The answer is simple, you need to provide easily scalable web security specification. Below I share my workflow for this. It includes web app, infra and compliance risks.

1. First-of-all we need to avoid reinventing the wheel. Review the security specification from well-known service providers like Google https://partner-security.withgoogle.com/docs/webapp_requirements.html. If you are going to accept payments and leverage third-party payment gateway like Stripe, it always make sense to review related Security Integration Guidelines (e.g. https://stripe.com/docs/security/guide)
2. Take security recommendations from OWASP top 10 and top 10 API. They contain widely known threat lists and proactive actions which need to be taken. These lists may seem redundant but you can keep only what you need. For example you don’t need to be protected from Injections if your web site is just landing. There is no user input, so this attack vector is not relevant.
3. Think about infrastructure security. Depends on your goals it can be a dedicated / managed / shared hosting. Don’t forget about physical security.
4. Compliance. How much pain in this word! Unfortunately, you have to think about it if you collect PII data (personally identifiable information). This point related to infrastructure security cause regulation depends on jurisdiction (local lows). Ask your hosting provider — does he comply with <REGULATORY_YOU_NEED>? Ask yourself where am I going to keep this data and what type are they? Provide relevant requirements into specification. Obfuscate or anonymise data if needed.

Also, below I listed the typical security criteria for almost any web application. It’s just a sample.

Hosting environment
Web Application must operate in a secure environment. Industry standards must be followed — ISO/IEC 27001, ISO/IEC 27017:2015, SOC 2.
At a minimum, the software used around the application must be up-to-date, and there must be no known vulnerabilities that can be patched. Further, the systems must be appropriately hardened, following the principle that anything that is not required should be removed.

Input Validation (IV)
Anything that is transmitted from the browser to the application can potentially be manipulated by a malicious actor. The Web Application must always assume that any user input can contain malicious payload. It’s recommended to use best practices to provide sufficient protection — https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html

• IV must be provided both on frontend and backend of Web Application
• IV must be applied on both syntactical and semantic levels
• Allow-list validation must be applied (not block/black lists)

Protection from Injections (SQL, XPath, Command, XSS, etc.)
A successful injection attack can read sensitive data from the database, modify database data (insert/update/delete), execute administration operations on a host which is used for DBMS. There are many ways to protect a web application from these threats. Input validation described above is the one of the most useful methods to prevent successful attack. There are no strict security requirements to cover this part.
Each variable in a Web Application must be protected. Ensuring that all variables go through validation and are then escaped or sanitized is known as perfect injection resistance.
Best practices should be followed: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html
The Web Application must be protected from typical injections:
https://github.com/payloadbox/sql-injection-payload-list
https://github.com/payloadbox/xss-payload-list
https://github.com/payloadbox/command-injection-payload-list

Protection from widely known vulnerabilities
The Web Application must not use vulnerable and obsoleted dependencies and components. All unnecessary services must be disabled. If a known vulnerability cannot be fixed, the owner of the Web Application (<company_name>) must be notified about it.

Logic Errors
The application must perform logic checks where appropriate. For example, an application must check and enforce that a user cannot buy a negative number of items from a web store, or that it is not possible to transfer a negative amount of money to another person’s account.

Encryption
In order to avoid having sensitive data read by an attacker while it is in transit, the Web Application that allows users to log in, or contains anything but public data, must be available solely over HTTPS.

Third Party Content
The Web Application must not disclosure sensitive or personal information to 3rd parties. Whitelisting of third-party scripts should be applied.

Secure protocols must be used
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#22-use-secure-protocols

Secure Cipher Suites must be used
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#23-use-secure-cipher-suites
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#26-use-strong-key-exchange
Weak and obsoleted cryptography algorithms must be disabled

HTTP Strict Transport Security must be deployed
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#46-deploy-http-strict-transport-security

Mixed Content must be eliminated
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#42-eliminate-mixed-content

Secure Cookies must be enabled
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#44-secure-cookies

SSL Certificate must be issued by reliable CA
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices#26-use-strong-key-exchange
Letsencrypt doesn’t fit these requirements

Logs and events
Administrator role must have access to logs and events of Web Application and hosting environment

Identity management
IAM must support Role-based access control (RBAC). All authentication events must be logged. In additional to traditional login/password authentication process, Google Identity Services (GIS) must be used for alternative authentication.