DEV Community

Discussion on: If you were tasked to conduct a security audit on a server/database-backed web app, where would you start?

View post
Collapse
 
simbo1905 profile image
Simon Massey • • Edited
  • What's the security policy for the code. If it's on public git service (eg GitHub) is 2FA enabled for all contributors
  • is git branch protection enabled with at least one reviewer. That way a worm writing a rogue dependency into package.json is less like to slip something in
  • how are secrets handled such as database credentials. are they git-secret encrypted and strong.
  • does the configured database user have too much privileges (uses ”admin” or ”postgres” accounts) it should be a none default account granted the minimum privileges possible
  • are the default accounts of the database secured with strong passwords.
  • is there regular backups of the database. are they encrypted before moving off the host to a secure location. is the restore of backups regularly tested.
  • is there a CI/CD pipeline and does it have security vulnerability scanning enabled (snyk.io) and is the build failed for anything other than low severity issues
  • are low severity security scanned issues regularly reviewed and fixed by default. those that wont be fixed is the reason documented and peer reviewed (eg ”we don't use that logic”). are those reasons periodically reviewed to check they are still valid
  • are deployments against git tagged versions of the code. have branch protection and githooks been set to prevent updating tags or forces rewrites of history in git that could hide the history of a backdoor being added into the code base
  • are git release tags annotated tags and gpg signed ’git tag -s’ so that we know exactly who said that version of the code is good to release in a way that cannot be faked
  • is the OS or base container layer up to date and regularly patched. stale Dockerfiles and images with cached out-of-date base image layers is sadly typical. the release build should run with flags to disable layer caching to force download of latest patches from upstream
  • does the code run on the current long term support version(s) of the web technology it uses. is there a policy to promptly upgrade to support the next long term support version and a deprecate support for expired versions.
  • is the software frequently rebuilt and redeployed pick up newly discovered security issues (if the code is only pushed every few months known security bugs are not fixed for months)
  • is HTTPS enforced and is the cert properly protected (such as git-secret encrypted)
  • is 2FA enforced for access to all infrastructure (eg AWS account)
  • is the app appropriately firewalled (only specific ports enabled)
  • are docker images running as root (mostly everything on hub.docker.com does) you should only docker images as a regular user. s2i images typically do this properly if you need a move away from root images.
  • is there a ”security” label for bugs in the issue tracker and are issues with that label prioritised with a low response time to triage them rather than just ignoring it as not a fun feature to build.
  • did the app write it's own authentication and authorization logic. if it did that's an epic fail.
  • does the app allow the forcing of 2FA for privileged accounts
  • is all input to the app sanitised (library to scrub SQL injection)
  • is static code analysis being applied to the code base and the build failed for issues. most security bugs are simple code errors and code that passes a lint is likely to have less bugs so less holes
  • is there peer review of all pull requests. most security bugs are simple code errors and code that is clear and understood by two devs is less likely to have bugs that lead to security errors
  • has penetration testing been performed against the application
  • has the codebase been reviewed to ensure that role based access control is properly enforced
  • are cookies handled correctly such as marked as secure so only sent over HTTPS
  • are assets loaded from public CDN which may be a route to inject attacks. use your own CDN and ensure you checked the hash for the files you put there against the official releases or built them yourself
  • check CORS correctly configured and XSRF protection in place
  • are passwords correctly stretched and salted or better yet use SRP6a authentication protocol
  • are users emailed on and changes to their account
  • are strong passwords enforced? check part of the hash of passwords against the Troy Hnt ”have I been pwned” API of half a billion compromised passwords.
  • is the login screen tested against the most popular password managers so that users can use randomised strong passwords
  • are the users offered recovery codes or password recovery using shamir secret sharing scheme