Any and all interaction with the database should done using either Stored or Prepared Procedures
Prepared statements, yes, stored procs, NO.
SPs never really increase security (unless you are talking about the DA's job security), but they do complicate the design. Therefore, you shouldn't use them "just because". Most apps these days use some form of
ORM and a minimal set of sprocs, if any.
HTTP Response Header Requirements- All cookies to have the "HttpOnly" and "Secure" attributes
HTTP Headers should not include Server OS versionHTTP Headers should not include Web Server version- HTTP Headers must include an X-Frame-Options directive
Security though obscurity isn't real security. The hacker isn't going to look at your headers and then run a specific exploit script; they'll just run them all and then some. My Apache logs are full of attempts to exploit IIS vulnerabilities, every day.
Also you can't really expect the client to honor any particular headers, either. (You should still use the security attributes, ofc, just don't count on them working).
All passwords should be stored using one way encryption with a unique salt per user (salt to be a minimum 128bits)
- Don't invent your own cryptography.
- Use the
Unix crypt scheme with a
NIST approved algorithm for password hashing.
- Require strong passwords.
- Introduce some sort of
one-time password scheme in addition to the static one.
- Don't do
wish-it-was-two-factor. It's just unnecessary if not embarrasing.
- Where the need for database analysis is required the data should be purged of all PII prior to be delivered to the auditor
There is no need to purge anything if you follow a proper release managment process.
You should have at least three different environments: development, QA and production. Dev never sees the production data, and it's where you do all your development and most of your analysis. QA is a replica of the production, used for testing the releases before moving them into production. QA can also serve as a backup when production goes down.
- Users with permissions to the database should be limited to the web application only
You can have different kinds of access schemes, but basically only a select few should have any type of access to production (or QA) DB or OS (or even apps).
Another good idea to discuss it the limit that can be transfered daily/hourly.
For instance, setting a maximum dollar amount to transfer out is pointless as you can simply crash the price and pull out. Perhaps a better idea would be to set volume limits instead?
You could use a 48+ hour average or something.
There could be rules to detect suspicious activity (sudden spikes in volume etc) which could trigger safety measures, such as seizing trade and withdrawals completely until the activity has been audited.