DVGM/doc/exercises/02-dynamic-analysis-with-arachni.md

Dynamic Analysis: Arachni

Arachni is a web application security scanner framework that supports many different kinds of security checks, including detection of insecure header, cross-site scripting (XSS), SQL injection, and cross-site request forgery (CSRF). We will run the tool twice; first on the login page, then we will provide the login credentials for a student to the tool -- otherwise, Arachni would not see much beside the login screen, similar to an unauthenticated user.

Running Arachni without credentials

In order to run Arachni, start it with the following options:

arachni --report-save-path=/tmp/sign_in_page.report \
  --check=unencrypted_password_forms,x_frame_options \
  --scope-exclude-pattern='/assets/|__web_console' \
  http://$(hostname):3000

To speed up the analysis, we only use the unencrypted_password_forms and x_frame_options check, because this is the only one that will yield a result at this point. If we would run Arachni with all checks enabled, it would take considerably longer. In addition, by using --scope-exclude-pattern, we tell Arachni to skip assets and the debug console of Ruby on Rails, which is active since we run the app in development mode. Otherwise, Arachni will loop for a long time trying to navigate the console.

Once the analysis is finished, inspect the report:

arachni_reporter \
  --reporter=html:outfile=/tmp/sign_in_page.html.zip \
  /tmp/sign_in_page.report 
unzip -d /tmp/sign_in_page /tmp/sign_in_page.html.zip
chromium /tmp/sign_in_page/index.html

Arachni should have found insecure headers and a possibly unsecured login page. Remember that Arachni was acting as an unauthenticated user, so it is not surprising that it found considerably less than brakeman.

Insecure HTTP Headers

1. What is the purpose of the missing headers?
2. How could the lack of these headers be used to attack DVGM?
3. Ruby aims to have secure defaults. Can you find which part of DVGM's sorce is responsible for the lack of said headers?
4. We have now used a static analysis tool, Brakeman, and started to use a dynamic tool, Arachni. What are some benefits and limitations of these different kind of tools?

Running Arachni with credentials

For the second run of Arachni, you will provide the login credentials for our student account, peter. This will allow Arachni to scan more parts of DVGM.

arachni --report-save-path=/tmp/logged_in.report \
  --plugin=autologin:url="http://$(hostname):3000/sign_in",\
    parameters="user_session[login]=peter&user_session[password]=football",\
    check="| Logout" \
  --scope-exclude-pattern="sign_out|__web_console|/new" \
  --check=code_injection,csrf,'xss*',hsts,\
    unencrypted_password_forms,allowed_methods,x_frame_options \
  http://$(hostname):3000

Again, the scan might take a few minutes. This time, we use the autologin plugin, which takes three parameters: url, the URL to the sign-in page; parameters, which contains the POST parameters that a browser sends when we type in username and password and submit the form; and check, which contains text that Arachni uses to check whether the login succeeded (only when we are logged in, we will find the text | Logout in the top bar). Additionally, we use more checks this time, because Arachni now has access to larger parts of our app. We also need to make sure to exclude URLs from the scan that includes sign_out| (we do not want Arachni to log out automatically) or /new|' (we do not want Arachni to end up in an infinite loop creating new grade comments).

Once the scan finishes, inspect the report:

arachni_reporter \
  --reporter=html:outfile=/tmp/logged_in.html.zip \
  /tmp/logged_in.report
unzip -d /tmp/logged_in /tmp/logged_in.html.zip
chromium /tmp/logged_in/index.html

Arachni should have found XSS and CSRF vulnerabilites.

5. We ran Arachni with the sql_injection plugin. Recall the SQL exploit that you found earlier. What could be a reason for Arachni not finding the SQL injection vulnerability?

DOM XSS / Client-Side XSS

6. Read through the two types of reported XSS issues. In particular, click on the eye button to inspect the injected seed along with the presented proof. Do you think the found issues are true positives? How does the automatic verification of the found XSS vulnerabilities work? How is the found XSS vulnerability different from the found DOM XSS vulnerability?

Cross-Site Request Forgery (CSRF)

7. Inspect the found cross-site request forgery attack. The Ruby on Rails Security Guide contains a good introduction to this kind of vulnerability. How can this kind of vulnerability be problematic found an app like DVGM? Compare the finding with the CSRF warning from Brakeman.