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

FULL DISCUSSION
 

If it's a question of where I would start, in the first hour:

  • Start learning how the request/response is implemented: Is it REST? Query-based? Some home-grown scheme? How is escaping done?
  • Start learning how they manage sessions: Session in Cookie? Session in LocalStorage? Session in URL?
  • Start learning why types of errors I can get it to throw: Can I get a 400-series? Any 500-series?

Once I get a good baseline of their public API, I try to imagine the type of development team that built the site:

  • Was the team experts or amateurs?
  • Did the team understand web security concepts or not?
  • Was the team senior or junior?
  • Was the team rushed for time or not?
  • Was there a lot of group-think in their decision-making process?

After that, I know where to go next. For example, if I see sloppy session management, can trigger 500 errors, and I think they're a junior team, I'll start looking for errors related to manipulating session data.

If I've got nothing after an hour, I usually give up. Usually, however, there's some thread to pull.

 

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

code of conduct - report abuse