Dev Training

# Dev Training
### Security Misconfiguration

## Overview

### About

* Extensive topic
* Depends on technology stack
    * Framework
    * Web servers
    * CI/CD pipeline
    * Third party software
    * Hosting (cloud)

### Major topics

* HTTP Headers and cookie flags
* Framework specific configuration
* Web server specific configuration
* Attack surface
* Default credentials

## HTTP headers and cookie flags

### What is it?

* These configurations instruct web clients (usually browsers) on
    * how to interact with your web application
    * how and where to allow content to be loaded from
    * how to allow access to certain data

### Cookie flags

|Flag| Purpose|
|------|-----|
|`HttpOnly`|Cookie cannot be accessed through client side script|
|`Secure`|Cookie will only be transmitted over HTTPS|
|`SameSite`|Control how cookies are sent across origins ([good overview](https://twitter.com/hackerscrolls/status/1343255733413027843/photo/1))|

### HTTP headers

* There is a fair number of security-related HTTP headers
* New ones are added frequently

### Prevent framing

`X-Frame-Options` (being phased out)

|Value|Meaning|
|-----|-------|
|`DENY`|Response cannot be rendered in an iframe|
|`SAMEORIGIN`|Response can only be rendered in an iframe originating from the same origin|
Note: Framing - embedding or framing a webpage within another webpage using iframe tags

### Strict transport security (HSTS)

`Strict-Transport-Security`

|Value|Meaning|
|-----|-------|
|`max-age=31536000`|Instructs the browser to only establish connections over HTTPS to the domain for the next year|
|`max-age=31536000; includeSubDomains`|Same as above, but also applies to subdomains|

### Content security policy (CSP)

* `Content-Security-Policy`
* Used to enforce where content can originate from
    * Including Javascript, images, CSS, etc.
* Very complex
* Common uses
    * Disallow inline Javascript (helps prevent XSS)
    * Only allow specific JS files from specific origins
    * Report violations to specified endpoint
* [Recommended reading](https://developers.google.com/web/fundamentals/security/csp)
* [CSP evaluator](https://csp-evaluator.withgoogle.com/)

### Prevent framing with CSP

`Content-Security-Policy: frame-ancestors <source>;`

|Value|Meaning|
|-----|-------|
|`'none'`|No URLs match|
|`'self'`|Only the current origin can embed the page|
|`<host>`|Allow specific hosts, URLs or IPs to embed the page|

## Framework specific configurations

### General

* Vary greatly between frameworks
* Common settings
    * Set various HTTP security headers (e.g., HSTS)
    * Application secret key (must be kept safe)
    * Disable error pages
    * Enable XSS filtering
* Disable debugging

## Web server

### General

* Configure access and error logs
* Set HTTP security headers
* Disable directory listing
* Disable unused modules (less attack surface)
* Set up and configure SSL

### Examples

### IIS

* By default, IIS can expose names of files and directories under the web root
    * Due to a legacy setting of *8.3 filenames* in Windows
* Test your web servers with [IIS Short Name Scanner](https://github.com/irsdl/IIS-ShortName-Scanner)

### Nginx - Location

```nginx
location /i/ {
    alias /data/w3/images/;
}
```

* Request to `/i/img.gif` will map to `/data/w3/images/img.gif`
* Accessing files outside of `images` won't work

### Nginx - Location

```nginx
location /i {
    alias /data/w3/images/;
}
```

* Location doesn't end with `/`
* The location `/i../app/config.py` maps to `/data/w3/app/config.py`

### Nginx - Directory listing

```nginx
location /var/www/ {
    autoindex on;
}
```

### Nginx - Directory listing

### Helpful resources

* Nginx
    * [NGINXConfig by DigitalOcean](https://www.digitalocean.com/community/tools/nginx) (Config generator)
    * [GIXY](https://github.com/yandex/gixy) (Config checker)
* Apache
    * [Apache hardening](https://geekflare.com/apache-web-server-hardening-security/)

## Up the stack

### More technology specific

* Cloud
    * Cloud opens the door for new security issues
    * Case in point: SSRF
* SaaS
    * Many mistakes can be made when using third-party services
* Hosting
    * Does the host have an update schedule?
    * Is hosting shared? How is it isolated?

## Attack surface

### Only expose what you need

* Every single attack surface you have is a potential risk
* If it is not essential for a service, account, server, etc., to be exposed, then don't expose it
* Risk accumulates as attack surface increases

### What is attack surface

* Accounts/privileges
    * Default accounts/credentials
* Dev/staging environments
    * Usually have poor credentials
* Pages/endpoints
    * Can expose valuable or sensitive information
* Services
    * FTP, Databases, etc.
* Ports/servers

### More attack surface

* CI/CD pipeline
* Third party services
* Cloud services
    * S3 buckets
* Container registries
* Code repositories
* Developers

### Decrease impact

* Separation of duties
* Isolation of services
    * This includes shared hosting

## Impact

### Best case

* No significant impact

### Worst case

* Complete takeover of infrastructure
* Sensitive data leak
* Backdoor

## Rules of thumb

### RTFM

* There is no silver bullet
* Read documentation and hardening guides that apply to your chosen languages/frameworks/technology stack

## Epilogue

### Further reading

* [OWASP - Security Misconfiguration](https://owasp.org/www-project-top-ten/2017/A6_2017-Security_Misconfiguration)
* [OWASP Secure Headers Project](https://owasp.org/www-project-secure-headers/)
* [OWASP Attack Surface Analysis](https://cheatsheetseries.owasp.org/cheatsheets/Attack_Surface_Analysis_Cheat_Sheet.html)

### Hall of fame

* [Exposed S3 buckets](https://github.com/nagwww/s3-leaks)
* [Stackoverflow](https://stackoverflow.blog/2021/01/25/a-deeper-dive-into-our-may-2019-security-incident/) (Secrets in VCS)