Skip to content

Instantly share code, notes, and snippets.

@evanrolfe

evanrolfe/risk_ledger_take_home_test.md

Last active December 20, 2021 13:34
Show Gist options
  • Save evanrolfe/9926d88d57523a3d067e8177fa13e2cd to your computer and use it in GitHub Desktop.
Save evanrolfe/9926d88d57523a3d067e8177fa13e2cd to your computer and use it in GitHub Desktop.
Download ZIP
Raw
risk_ledger_take_home_test.md

Risk Ledger Take Home Test - Authcov

(Evan Rolfe)

Authcov: https://github.com/authcov/authcov

There is a readme in the link above for this package which explains what it does and how it works. Below I have written some more details that are relevant to this job-application.

How I built it:

I initially wrote this package using the headless-chrome-crawler package as a dependency to do the crawling. However I had quite a few issues with this package - there was some weird and unexplained behaviour and it felt like I was bending my code backwards to make it work with it. So I copied the key parts of headless-chrome-crawler into the authcov package and re-worked it to suit my needs. The downside of this is that I now have to maintain my own crawler code. If I can use a third party package to do something then I would do that as a first choice, assuming that it's well tested, well maintained and not buggy, unfortunately that was not the case with headless-chrome-crawler.

I chose Nodejs for this package because the npm package puppeteer gives you (in my opinion) the best way to interface with the Chrome Dev-Tools API. Also Nodejs's promises, async/await features make it easy to write asynchronous code.

This was my first time working with Nodejs, although I was very familiar with javascript in a browser-based context. When I first wrote this in 2019, I had spent most of the last ~6 years working with Ruby on Rails, so the coding style is heavily influenced by Ruby i.e. using objects for everything! I've since migrated the codebase to use Typescript. In my current job I've been using Typescript and I now prefer to work with languages that have type-checking built in. There is still a portion of the codebase that is not yet typed, but I am gradually working towards having all code typed.

How I tested it:

I used a combination of unit tests, and end-to-end (e2e) tests. The e2e tests rely on a specific example web-app to be running locally. They run the crawler against that web app, and verify that the final results of the crawler are correct. There are pros and cons to this approach:

Pros:

  • It tests everything and gives a high level of confidence that the code is working correctly
  • It lets us refactor code easily because they only test the final output and are not coupled to the implementation itself (i.e. nothing is mocked)
  • Includes the chrome browser as part of the tests, this is important because the way chrome behaves can be unpredictable, its not something you can just mock out and assume it works the way you expect it to

Cons:

  • It's a bit slow to run these tests, takes around 30 secs on my machine.
  • When the tests fail it can be hard to track down what actually caused the failure because the failure could be from anywhere in the entire codebase
  • It's a bit clunky having to run a seperate web-app with docker-compose (this could be solved by implementing the web-app entirely in nodejs)

Because of those cons listed, I have also included unit tests, which are there to test highly specific behaviour of certains parts of the code. The pros/cons of the unit tests are the opposite of the pros/cons of e2e tests.

What potential security issues are there?

Authcov is intended to be run by developers, penetration testers or other security professionals, who would run it against either a web app they own or a web app they have permission to test.

One possible attack vector is that if the person who owned the web-app being tested inserted some malicious code to the web app, it would be picked up by the crawler, saved and displayed back in the generated report. This could potentially be used to perform privilege escalation i.e. if the report was shared with other people in a company it could let the attacker gain deeper access.

This is something I would expect a security professional to be aware of, though I think the likelihood of anybody pulling off such an attack is low.

Improvements to be made:

  • add more types to the functions
  • replace expample_app with something written purely in nodejs so it doesn't require docker to run
  • Figure out why the spa-button-click.spec.ts only passes when run individually - are there dependencies between the tests?
  • Use a code-coverage package to see just how much coverage the tests actually give
  • get rid of a deprecated dependency - the url package
  • Use CircleCI to run the tests in a CI environment on each commit / pull-request
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment