Skip to content

Commit

Permalink
Update 28.md
Browse files Browse the repository at this point in the history
  • Loading branch information
@nayong2021
nayong2021 committed Sep 21, 2023
1 parent e5ca66b commit 0d20efa
Showing 1 changed file with 159 additions and 11 deletions.
170 changes: 159 additions & 11 deletions 28.md
View file
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
# 28. SecurityBestPractices

## ~~28.1 Reference Security Sections in Other Chapters~~

## 28.2 Harden Your Servers

서버 강화에 대한 지침과 체크리스트를 온라인에서 검색하라. 서버 강화 조치에는 방화벽 설정(help.ubuntu.com/community/UFW), SSH 포트 변경, 불필요한 서비스 비활성화/제거 등이 포함되지만 이에 국한되는 것은 아니다.
Expand Down Expand Up @@ -34,8 +36,31 @@ CSRF_COOKIE_SECURE = True
```
참조: https://docs.djangoproject.com/en/3.2/topics/security/#ssl-https

<!-- ### 28.6.2 Use HTTP Strict Transport Security (HSTS) -->
<!-- ### 28.6.3 HTTPS Configuration Tools -->
### 28.6.2 Use HTTP Strict Transport Security (HSTS)

HSTS : Web Site에 접속할 때, 강제적으로 HTTPS Protocol로만 접속하게 하는 기능

HSTS가 작동하기 위해선 브라우저와 웹 서버 모두 지원해야 한다.

#### HSTS의 목적

사용자가 웹 사이트에 접속할 때, 주소창에 'http://' 또는 'https://' 를 입력하지 않고 접속하기 마련이다. 이 때, 브라우저는 **HTTP** 프로토콜로 먼저 통신을 시도하게 된다.

여기서 공격자는 사용자와 웹 사이트 사이의 통신을 가로채는 중간자 공격을 하여 사용자와는 **HTTP** 프로토콜로 통신하고 웹 서버와는 **HTTPS** 로 통신하면 사용자가 실제 site와 주고받는 정보가 공격자에게 노출되게 되지만 사용자는 전혀 눈치를 챌 수 없게된다.

**예제 28.2: HSTS Response Header**
```
Strict-Transport-Security: max-age=31536000; includeSubDomains
```

HSTS configuration 팁:

1. 처음 HSTS를 적용시켜 배포할 땐 max-age를 300과 같이 작은 값으로 설정하라. max-age가 한번 유저에게 설정된 뒤로는 웹 서버에서 변경할 수 없기 때문에 보안 설정에 실수가 없었는지 확인하기 위해선 max-age를 작은 값에서 시작해야 한다.
2. 그 다음 점차 max-age를 늘려가며 1년(31536000)까지 늘려가라.
3. max-age가 1년에 도달하게 된다면 HSTS preload를 위해 프로젝트를 https://hstspreload.org/ 에 제출하라. 이를 통해, 사용자의 첫 접속을 공격자가 가로채는 것을 방지할 수 있다.

## ~~28.6.3 HTTPS Configuration Tools~~

## 28.7 Use Allowed Hosts Validation (ALLOWED_HOSTS 설정하기)

## 28.8 Always Use CSRF Protection With HTTP Forms That Modify Data
Expand All @@ -44,9 +69,48 @@ CSRF_COOKIE_SECURE = True

GET 메소드를 사용하는 유일한 예외상황은 검색 양식에 대한 것이다. 여기서는 사용자가 URL에 인수를 표시하는 것이 유용하다.

<!-- ## 28.9 Prevent Against Cross-Site Scripting (XSS) Attacks -->
## 28.9 Prevent Against Cross-Site Scripting (XSS) Attacks

[XSS(Cross Site Scripting) 공격이란?](https://4rgos.tistory.com/1)

### ~~28.9.1 Use format_html Over mark_safe~~

### 28.9.2 Don’t Allow Users to Set Individual HTML Tag Attributes

<!-- ## 28.10 Defend Against Python Code Injection Attacks -->
사용자가 HTML 태그의 개별 속성을 설정하도록 허용하면 악성 JavaScript를 주입할 수 있는 기회가 제공됩니다.

### ~~28.9.3 Use JSON Encoding for Data Consumed by JavaScript~~

### 28.9.4 Beware Unusual JavaScript

JavaScript의 문법으로 인해 매우 작은 문자 하위 집합으로 구문적으로 유효하고 실행 가능한 프로그램을 구성하는 것이 가능하다. https://jsfuck.com/ 에 따르면, 평범해 보이는 JavaScript를 단 6자(더하기 기호, 느낌표, 열기/닫기 괄호 및 열기/닫기 괄호)의 알파벳으로 변환하는 것이 가능하다.

## 28.10 Defend Against Python Code Injection Attacks

### 28.10.1 Python Built-Ins That Execute Code

eval(), exec() 그리고 execfile() 함수를 활용함에 있어 조심하라. 프로젝트에서 임의의 문자열이나 파일이 이러한 함수에 전달되도록 허용하는 경우 시스템이 공격에 노출된 상태가 된다.

참조 : https://nedbatchelder.com/blog/201206/eval_really_is_dangerous.html

### 28.10.2 Python Standard Library Modules That Can Execute Code

절대 파이썬 표준 라이브러리 [pickle](https://docs.python.org/3/library/pickle.html)을 이용해서 사용자가 수정했을 수 있는 데이터를 추출해선 안된다.

참조: https://lincolnloop.com/insights/playing-pickle-security/

### 28.10.3 Third-Party Libraries That Can Execute Code

PyYAML을 사용해 외부의 YAML 문서를 읽어야 할 때는 safe_load()를 사용하라. 어떤이들은 yaml.load()의 이름을 yaml.dangerous_load()로 바꿔야 한다고 말하기도 한다.

### 28.10.4 Be Careful With Cookie-Based Sessions

Cookie-Based Sessions를 사용할 때 주의해야 할 점:

1. 유저가 쿠키 기반 세션의 내용을 열람하는 것이 가능하다.
2. 공격자가 프로젝트의 SECRET_KEY에 대한 액세스 권한을 얻고 session serializer가 JSON 기반인 경우 session data 를 위조할 수 있는 능력을 얻게 되므로 인증이 사용되는 곳에 모든 유저로 위장할 수 있다.
3. 공격자가 프로젝트의 SECRET_KEY에 대한 액세스 권한을 얻고 session serializer가 pickle 기반인 경우 session data를 위조할 수 있을 뿐만 아니라 임의 코드를 실행할 수도 있다. 즉, 새로운 권리와 특권을 가질 수 있을 뿐만 아니라 작동하는 Python 코드를 업로드할 수도 있다.
4. session이 보장된 방식으로 무효화될 수 없다(만료되는 경우 제외). 브라우저에서 쿠키를 새 값으로 재정의하려고 시도할 수 있지만 공격자가 사용하도록 강제할 수는 없다. 이전 쿠키를 사용하여 계속 요청을 보내면 서버가 차이점을 알 수 없다.

## 28.11 Validate All Incoming Data With Django Forms

Expand All @@ -59,13 +123,42 @@ Django form은 웹 소스가 아닌 소스를 포함하여 프로젝트로 가
## 28.12 Disable the Autocomplete on Payment Fields

<!-- ## 28.13 Handle User-Uploaded Files Carefully -->
## 28.14 Don’t Use ModelForms.Meta.exclude

## 28.15 Don’t Use ModelForms.Meta.fields = ```"__all__"```

<!-- ## 28.16 Beware of SQL Injection Attacks -->
<!-- ## 28.17 Don’t Store Unnecessary Data -->
## 28.16 Beware of SQL Injection Attacks

Django ORM은 악성 임의 SQL 코드를 실행하려는 사용자로부터 사이트를 보호하는 적절하게 이스케이프된 SQL을 생성한다.
Django를 사용하면 ORM을 우회하고 raw SQL을 통해 데이터베이스에 더 직접적으로 액세스할 수 있다. 이 기능을 사용할 때 SQL 코드를 적절하게 이스케이프 처리하도록 특히 주의하라.
- .raw() ORM method.
- .extra() ORM method.
- Directly accessing the database cursor.

## 28.17 Don’t Store Unnecessary Data

### 28.17.1 Never Store Credit Card Data

PCI-DSS 보안 표준(https://www.pcisecuritystandards.org/)을 잘 이해하고 PCI 규정 준수를 검증할 적절한 시간/자원/자금이 없다면 신용 카드 데이터를 저장하는 것은 책임이 너무 크므로 피해야 한다.

대신, 써드파티 전자상거래 서비스를 활용하라.

> [!NOTE]
> TIP: Educate Yourself on PCI Compliance
>
> Ken Cochrane은 PCI 규정 준수에 대한 게시글
>
>https://www.kencochrane.com/blog/2012/01/developers-guide-to-pci-compliant-web-applications/
>
>를 읽어보기 바란다.

> [!NOTE]
> TIP: Read the Source Code of Open Source E-Commerce Solutions
> 기존 오픈 소스 Django 전자 상거래 솔루션을 사용하려는 경우 솔루션이 결제를 처리하는 방법을 검토하라. 신용 카드 데이터가 데이터베이스에 암호화되어 저장되는 경우 다른 솔루션을 사용하라.
### 28.17.2 Don’t Store PII(Personally Identifying Information) or PHI(Protected Health Information) Unless Required (By Law)

## 28.18 Monitor Your Sites

## 28.19 Keep Your Dependencies Up-to-Date
Expand All @@ -79,8 +172,15 @@ Clickjacking은 악성 사이트가 사용자가 숨겨진 프레임이나 ifram
참조: https://docs.djangoproject.com/en/3.2/ref/clickjacking/
![Clickjacking](image.png)

<!-- ## 28.21 Guard Against XML Bombing With defusedxml -->
<!-- ## 28.22 Explore Two-Factor Authentication -->
## 28.21 Guard Against XML Bombing With defusedxml

lxml과 같은 써드파티 파이썬 라이브러리는 잘 알려진 XML 기반 공격에 취약하다.

이를 방지하기 위해선 defusedxml 라이브러리를 사용하는것이 좋다.

참조: [Billion Laughs](https://en.wikipedia.org/wiki/Billion_laughs_attack), [Python및 Python 라이브러리 취약점 목록](https://pypi.org/project/defusedxml/#python-xml-libraries), [defusedxml](https://pypi.org/project/defusedxml/)

## 28.22 Explore Two-Factor Authentication

## 28.23 Embrace SecurityMiddleware
## 28.24 Force the Use of Strong Passwords
Expand All @@ -95,7 +195,14 @@ Clickjacking은 악성 사이트가 사용자가 숨겨진 프레임이나 ifram

비밀번호 복사/붙여넣기를 허용하지 않으면. 사용자가 기억하기 쉽거나 반복적으로 사용되는 비밀번호에 의존하도록 권장하는 anti-pattern이다.

<!-- ## 28.26 Give Your Site a Security Checkup -->
## 28.26 Give Your Site a Security Checkup

사이트에 대한 보안 자동점검을 제공하는 서비스를 통해 취약점을 확인하라.

자동점검 서비스 예시 : [Observatory](observatory.mozilla.org).

또한 pyup.io의 보안점검 라이브러리 [Safety](https://github.com/pyupio/safety)는 프로젝트 종속성을 확인하여 알려진 보안 취약점을 확인한다.

## 28.27 Put Up a Vulnerability Reporting Page

사용자가 보안 취약점을 보고할 수 있는 방법에 대한 정보를 사이트에 게시하는 것은 좋은 방법이다.
Expand Down Expand Up @@ -143,7 +250,48 @@ UUID('0b0fb68e-5b06-44af-845a-01b6df5e0967')
```
## 28.29 Upgrade Password Hasher to Argon2

<!-- ## 28.30 Use SRI When Loading Static Assets From External Sources -->
## 28.30 Use SRI When Loading Static Assets From External Sources

**예제 28.11: Naively Loading Bootstrap Assets**
```html
<!-- DON'T DO THIS - loading static assets without SRI -->
<link
rel="stylesheet"
href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css">
>
<script
src="https://code.jquery.com/jquery-3.3.1.slim.min.js"></script>
<script
src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.7/umd/popper.min.js"></
<script
src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js"></script>
```

**예제 28.12: Using SRI When Loading Bootstrap Assets**
```html
<!-- Loading Static Assets with SRI -->
<link rel="stylesheet"
href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css"
integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T"
crossorigin="anonymous">
<script src="https://code.jquery.com/jquery-3.3.1.slim.min.js"
integrity="sha384-q8i/X+965DzO0rT7abK41JStQIAqVgRVzpbzo5smXKp4YfRvH+8abtTE1Pi6jizo"
crossorigin="anonymous"></script>
<script
src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.14.7/umd/popper.min.js"
integrity="sha384-UO2eT0CpHqdSJQ6hJty5KVphtPhzWj9WO1clHTMGa3JDZwrnQq4sF86dIHNDz0W1"crossorigin="anonymous"></script>
<script
src="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/js/bootstrap.min.js"
integrity="sha384-JjSmVgyd0p3pXB1rRibZUAYoIIy6OrQ6VrjIEaFf/nJGzIxFDsf4x0xIM+B07jRM"
crossorigin="anonymous"></script>
```

SRI(Subresource Integrity): 써드파티 리소스가 변조되지 않았음을 확신할 수 있도록 하는 W3C 사양

#### 작동원리

브라우저가 integrity 속성을 가진 ```<script>``` 나 ```<link>``` 요소를 발견하면 실행하기 전에 integrity 속성에 담겨진 해시 값과 명시된 경로에 위치한 실제 js 또는 css 파일 등이 일치하는 지를 검사하게 된다. 일치하지 않는다면 브라우저는 해당 리소스의 실행을 거부하고 fetching이 실패했다는 것을 알리는 네트워크 에러를 리턴한다.

## 28.31 Reference Our Security Settings Appendix
## 28.32 Review the List of Security Packages
## 28.33 Keep Up-to-Date on General Security Practices

0 comments on commit 0d20efa

Please sign in to comment.