Let's say you were brought on to inspect and a company's web app, built on something common like PHP/Rails/Node/etc.
What's your check list, what are you looking for?
Let's say you were brought on to inspect and a company's web app, built on something common like PHP/Rails/Node/etc.
What's your check list, what are you looking for?
For further actions, you may consider blocking this person and/or reporting abuse
Matheus Almeida Costa -
Michael Tharrington -
Dev on Remote -
Jaydeep Pipaliya -
Latest comments (38)
Lot of professional answers but I would start by looking how many keys are stored in plain text in config file on backend server.
I would also check how many of these are used by the frontend. Some developers leave keys embedded in HTML like hidden input and sometimes you can get the key by inspecting network traffick with dev tools in browser if your app frontend uses 3rd party api but tries to hide the key by uglifying JS. Many forget to keep the keys on back and act as a middleware.
Then classics like sql injection, xss, those kind of things.
Later I would call sec experts to check for real threats which are security stuff and not common mistakes.
As @andrew_brown pointed out OWASP and Kali have a lot of amazing tools. I would recommend every company to use ZAP from OWASP as a good starting point. It has a big list of automated tests which of course need you to verify afterwards manually or using other tools but it does warn on many things.
owasp.org/index.php/OWASP_Zed_Atta...
The responses posted provide good information. The only thing I would add is referencing the OWASP ASVS (application security verification standard) as it describes the security that should be built into the application - input handling, session management, use of secure ciphers, privileged command execution etc. This is the link to OWASP ASVS:
owasp.org/images/3/33/OWASP_Applic...
The other item I didn't see mentioned (I may have missed it) but is proper implementation of TLS.
Additional considerations include application and database configuration and secure configuration of the execution venue. Running the application on AWS EC2 instances versus GCP GKE (intentionally drawing a stark contrast) brings different security considerations.
You should check:
For the majority, you will be dealing, very likely, with outdated servers and unauthorized access or improper permissions for user access.
I would start from the back of the stack and work towards the front end. The theory being that locking down the DB operations and access will give the most benefit vs time spent as the source is secure. Then I would start fanning out to any services that interact with the data source and make sure they are secure. Lastly moving on to any clients that interact with those services.
The first thing to check is if they’re using the default admin account on the database and if it is still using the default password or something easily crackable. You’d be surprised...
OWASP has a great web app testing methodology guide to walk you through a bunch of checks: owasp.org/index.php/Web_Applicatio...
These are kind of the minimum, a tester would want to expand based on what behavior exists in the application, but that guide is a great baseline.
Also, business logic inconsistencies and access control misconfigurations (or failures) are something I prioritize, as these are the kind of things an automated scanner or tool is not really able to find.
I would check if there's any session checking / auth verification.
Most of big non-tech company rely too much on VPN and don't invest money on security, thinking that it would not be possible for someone to actually access to an app without getting inside the network.
When was the last time they practiced a DR drill? Or just start with what was the last time they verified a database backup?
Identity management is huge too. How many SSH keys are in circulation? Who all has the capability to create keys to PROD servers. They do use different keys for PROD, right?
Don't focus all on PROD. If they have a DEV server that's running a backup of PROD, then there is potentially hundreds of gigabytes of PII on a server with the most minimal of defenses.
If you have the opportunity to set up an app-level account, there's still a non-trivial number of sites that you can get a basic idea of the implementation-language by the characters you're not allowed to use in passwords. Sadly, many of them are banking-sites. :p
Focus on the human element of the organisation structure plus try to grab the laptop of the middle manager to see you are able to gain access to it
Assuming I just wanted to get a quick one day check of things, and not a thorough security review, this is what I would look at:
There are free SAST and DAST tools available that could be useful to get a baseline done pretty quickly. For example the OWASP ZAP project.
I would think about logging, alerting, and other APM stuff. If they don't know what kind of errors and issues are happening then they probably couldn't detect a hack. If they are logging things, then what are they paying attention to?
Next up would be dependency management and other general coding practices. Is there a code review process, are there quality gates? How are defects resolved? How (if ever) do they update dependencies?
I would look at application boundaries. Where does data enter and leave the application? Is it sanitized and encoded? What is the overall risk exposure of the application e.g. if someone nefarious got access could they affect other apps/systems at the company? How much attack surface is there?.
Finally I would take a quick look at authentication and authorization. Are the APIs open to the public? How do they handle user logins. Time wise it would take a lot of effort to review this (and I just don't have the skill to do so).
I would start with the human layer of the stack. Who has access, what are their permissions, are accounts shared, password requirements, etc.