I've had to analyse security of web applications, either for Due Dilligence or with a view to how secure my own (developed) web applications are. The OWASP top 10 is both a good set of metrics (in as much as it covers what should be covered) and is independant of any commercial slant.
I use Prepared Statements to prevent SQL injection. All user data place into the database uses prepared statements separating variables from the command string.
This is 100% a backend/developer responsibility. I cover HTML injection under XSS, see item 7.
I require multi-factor authentication (using TOTP) and complex* passwords. Passwords are stored with one way encryption. The TOTP secret key is stored AES-256 encrypted with the password used as the key, unless the use case needs the TOTP for out of band authentication (say by telephone)
ini_set("session.use_trans_sid", false);
ini_set("session.use_only_cookies", true);
ini_set("session.cookie_secure", true);
ini_set("session.cookie_samesite", "Strict");
Store the authenticating IP address in a server-side session. If the session cookie is returned from an IP address that does not match the server-side IP the session is invalidated.
There is a happy medium around password complexity. When combined with TOTP (which I do) this should move from technical enforcement to user education...
Data can be exposed whilst at rest, in motion or in use. I deal with sensitive data specifically as defined by the ICO in GDPR (Personal Data and Sensitive Personal Data) and in PSD2 as Sensitive Payment Data.
...is not encrypted, but is at rest in ISO270001 physical security and access to the VPS is protected with a layer 3 firewall that is audited from an external source
...all in motion dayta is treated equally as sensitive data. My web applications use http with TLS and Apache which is configured to use only strong cipher suites (SSLCipherSuite AES256) and add a Strict-Transport-Security "max-age=63072000; includeSubdomains;" header
In one case I've experimented with client side certificates.
...I always viewed this to cover data in a CPU, or RAM (not a RAM drive, but an ephemeral data structure specific to the program) or ona VDU. This recent case might change that, but until there is some concensus view I view Data in Use protection as a User Education issue (sure there are things that can be done like active javascript session timeouts).
I'm not a great user of XML so I ignore this as out of scope for my projects unless they need to process XML.
Role Based Access Control (RBAC) is the best solution here. Role can be externally managed in a directory (I've used LDAP and Active Directory) or a JSON blob in a MySQL / MariaDB database
Any parameters that might need to be examined for account separation are considered each time the URI is parsed for parameters
Once this is set up it falls to a human/committee to audit role changes and what roles can run what programs. I use a table to show users and role membership and programs / funcitons are permissioned to roles as they are created.
I use LAMP, the components are guessable and I don't have any massive faith in security through obscurity, so I'm OK for software versions to "leak" and I'm not a fan of generic error messages (a pain for debugging) for logged in users. I agree that programmers should consider what is leaked in exception messages.
configuration is beyond the scope of this (Web Application) document, but the operating system is regularly updated and has a number of protections in place.
Header always set X-XSS-Protection "1; mode=block" Header always set Strict-Transport-Security "max-age=63072000; includeSubdomains;" Header always append X-Frame-Options SAMEORIGIN Header always set X-Content-Type-Options nosniff Header always set Expect-CT "enforce, max-age=300,report-uri='https://extranet.bidetreasury.com/'"
Public access to port 3306 is blocked. On sufficiently complex projects schema is spread across databases and DB users are permissioned accordingly. The DBMS is regularly upgraded.
is regularly upgraded and aspects of the code discussed in other headings in this document
The environment is regularly scanned with a vulnerability scanner (I use Nikto and OWAP ZAP) to check for known misconfigurations
... is prevented by using input sanitisation. PHP strip_tags is used for any string data that is not more vigorously checked against regex or type matched and htmlentities for rendering sanitised and unsanitised data in form input.
... see headers documented in ?Security Misconfiguration? that provide further layers of mitigation
I don't make enough use of Anti-CSRF tokens on state change actions because they break multiple tab browsing, but I have used it and consider it a good solution to the problem.
... used to both transmit data from the backend to the UI and to store in MySQL/MariaDB. Where JSON data is provided as input (from a UI or anywhere other than MySQL/MariaDB) a parsing check is made and an exception raised if there is a failure.
I rely on PHP to correctly create a valid data structure from this. Individual components are ofcourse validated.
The serialzed data never leaves the server nor is it manipulated to outside of the PHP session handler. The file has limited permissions to prevent any unprivileged local user from accessing it.
Where I am involved long term with the project I have an inventory of components uses and update the component and test where necessary. I also use Nikto and OWAP ZAP to report on known Vulnerabilities.
Log in attemps are logged and where I'm able (sufficient control of the project environment) these are fed back into a layer 3 firewall to deny further access for 24hrs. I also use ip.info to resolve IPs back to AS numbers to finger print access. And external system could (but I've not done this yet) disable accounts that don't match, currently they just send an email that feeds into an Incident Response Policy.