237 Web application security [4d]

Web security basics

Einführung in die Web Security 🇩🇪 Show archive.org snapshot provides essentials for the topic of this card.

Read following chapters:

(1) Security Principles
(3.3) Sessions and Cookies
(3.5) Same-Origin-Policy
(4.2) Angriffsfläche / Attack Surface
(4.3) Speicherung von Passwörtern
(6) Kryptographische Grundlagen
(7) Authentifikation
(8) Authorization
(9) Session Management
- Ohne (9.4) JSON Web Tokens
(10) Federation / Single-Sign on
(11) Serverseitige Angriffe
(12) Clientseitige Angriffe
(13) Clientseitige Schutzmaßnahmen

Read through the most known security issues in web application, often known as "OWASP Top 10":
https://owasp.org/www-project-top-ten/ Show archive.org snapshot

Rails security

Read the following sections from the Rails security guide Show archive.org snapshot . For each section you should understand the security issue and what tools Rails gives you to address it.

Cross-Site Request Forgery (CSRF)
SQL Injection
Cross-Site Scripting (XSS)
Content Security Policy
- Also A reasonable default Content Security Policy for Rails

Understand the problem that is addressed by strong parameters Show archive.org snapshot (now part of Rails)

Understand how Rails protect you against injecting unwanted HTML tags.

Read Preventing users from uploading malicious content.

Exercise: Controller review

Assume our application has some PDF files with documentation:

app/
config/
db/
documents/
  markdown.pdf
  search.pdf
  registration.pdf
lib/
...

We want to link to a document like this:

= link_to 'Markdown help', '/help?doc=markdown'

So we add a controller that delivers the PDF:

get '/help', to: 'help#download'

class HelpController < ApplicationController

  def download
    pdf_path = Rails.root + "/documents/" + params[:doc] + ".pdf"
    send_file pdf_path
  end

end

Is it a good idea to build the controller that way? Can you improve it?

Tip

Get into a habit of reading code through the eyes of an attacker with bad intentions.

Exercise: XSS in Rails

Intentionally make MovieDB vulnerable to HTML code injection
Boot up a second Rails application on another port (e.g. rails server -p 4000 to boot it on http://localhost:4000). Assume this is a second domain under the attacker's control.
Exploit your vulnerability by sending MovieDB's cookies to the attacker's Rails app.

Exercise: Brakeman analysis

Brakeman Show archive.org snapshot is a static analysis tool which checks Ruby on Rails applications for security vulnerabilities.

Read our corresponding guide, then run brakeman -I on your MovieDB.

If it doesn't find any issues, run it on one of the sample apps you checked out earlier.
In any case, add a new spec to your MovieDB. It should check that brakeman does not find any (non-ignored) issues.

Understand a few of the warnings and their specific impact on the application you scanned. Could an attacker leverage the issue if we don't address it?

Vulnerabilities in dependencies

Every dependency that you add to your project can have security vulnerabilities. The dependencies of your apps are Ruby, Rails, all other gems and JavaScript libraries.

Find out what a CVE advisory is. Understand how we're dealing with security issues when new CVEs affect our applications.

How does our product Rails LTS Show archive.org snapshot work? Why do people pay money for it?

Exercise: bundler-audit

bundler-audit Show archive.org snapshot checks for vulnerable gem versions in your Gemfile.lock.

Run bundler-audit on your MovieDB. If it doesn't find any issues, run it on one of the sample apps you checked out earlier.

Understand a few of the warnings and their specific impact on the application you scanned. Could an attacker leverage the issue if we don't address it?

HTTPS

Learn about HTTPS Show archive.org snapshot ("SSL"). HTTPS gives us many useful guarantees. Most of the time we do not need to think about cryptography when we know there is HTTPS. However, HTTPS also has some limitations.

Exercise

Assume an attacker takes over the router box on your local network. The attacker can see and change any network communication between your PC and the internet.

Unaware of the attacker, you purchase articles in an online shop. Answer the following questions for both cases (1) with HTTP and (2) with HTTPS:

Can the attacker see that you're accessing the shop?
Can the attacker see how often you're accessing the shop?
Can the attacker see what articles you're browsing?
Can the attacker copy your session cookies?
Can the attacker record the network traffic while you're making a request, then send the same bytes from their own machine and get the same response ("replay attack")?
Can the attacker set up a fake web app on your local network and respond to your requests to the shop?
Is it safe to give your credit card information to a shop with a valid SSL certificate?