Skip to content

Instantly share code, notes, and snippets.

@tin-z

tin-z/app_rev_process.md

Last active December 11, 2022 15:05
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save tin-z/b5da60a56947b03c977baf260d687601 to your computer and use it in GitHub Desktop.
Save tin-z/b5da60a56947b03c977baf260d687601 to your computer and use it in GitHub Desktop.
Download ZIP
Application Review Process
Raw
app_rev_process.md

Overview of the Application Review Process

  1. Preassessment: Planning, scoping, collecting info and doc

  2. Application review: Design review, code review. Several strategies adopted to learn more about the application

  3. Documentation and analysis: Collecting and documenting the results of the review, risk analysis, remediations

  4. Remediation support: Evaluating fixes, recheck phase


dict()

1. Preassessment:

  • scope: Target. Find the most significant vulnerability in the shortest time (vuln researcher). Getting the best application coverage the project’s budget allows (security consultant). Periodic internal review (dev, security eng)

  • application access: source only, binary only, both source and binary, binary with the debugging symbols, black box (no binary access)

  • timelines: activity scheduling

  • Information Collection: Learning about the application’s purpose and function, threat modeling, read docs, study old vulns


2. Application review:

  • notes: avoid drowning, use different switchable methodologies/techniques. Follow an iterative process and reapt it max 3 times in a day. This process can be summed up in three basic steps: (1) plan what component/strategy you want to do next, strategy, etc. (2) work on that component and take notes based on the strategy. Write notes/working papers to transfer knowledge to another auditor and help distributing work among an auditing team. (3) reflect on the results before planning again, consider your goals.

  • Top-Down strategy: Use the initial knowledge of the application and refine it by conducting implementation assessments. This approach identifies design vulnerabilities first, followed by log bugs and then low-level implementation vulnerabilities.

  • Bottom-Up Approach: Review low-level code. Slow, a lot of code that isn’t security relevant, but maintaining and updating a design model of the system throughout the assessment is valuable through the iterative process as it can help to quickly piece together the higher-level organization.

  • Hybrid approach: combination of the top-down and bottom-up methods, alternating your approach as needed for different portions of an application.

  • Master Ideas List: Ideas on how you could exploit the system (this list isn’t detailed). It represent an intuitive understanding of the code So it’s a good idea to capture them when they hit you and test them when time is available.

  • Don’t Fall Down Rabbit Holes: trying to figure out technical issues until you lose track of what your initial goal was. Of course sometimes this is necessary, balance your time / milestones, this might mean you have to ignore something to give good coverage quality within your deadline. Before changing target write down all the paths you went on and would like to continue on the target next time

  • Take Breaks as Needed: your brain will work also in the shadow, just give him time to process the stuff.

  • Reflect: after a break do shadow learning. Status check: also consider time/milestones constraints of the activity. Peer reviews: Another point of view from another code auditor


Code auditing tactics

  • interprocedural analyses

  • Internal Flow Analysis: intraprocedural code and data flow analyses

  • error-checking flow: what happens when the error does occur, the error-handling code belongs to a code path that’s hardly ever traversed and probably not as well tested and audited.

  • Pathological code paths: describe functions with many small and nonterminating branches

  • Subsystem and Dependency Analysis

  • string analysis

  • Rereading Code

  • Desk-Checking: technique consisting of creating a table of all variables in a code fragment and then populating them with some initial values. Also consider performing data flow analysis (e.g. RDA)

  • Test cases: read them as they are usually meant for testing a small isolated part of code.


Code Auditor’s Toolbox

  • Source Code Navigators, debuggers, Binary Navigation Tools, diffing tools, fuzzing frameworks

ref

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment