哈啰，我们又见面了，昨天提到了 XSS、CSRF、Injection、Clickjacking 的安全议题，今天继续深入研究，在 Django 这个以 Python 为主的后端框架，帮我们做了哪些安全议题的防护措施，类此够 ~ (今天依旧是参考官方文件作为文章大纲)

1. SSL/HTTPS

不同于前面几个项目，SSL/HTTPS 不是一种攻击手法，反而是一种防御方法，透过加密的传输通道，让我们的资料传递过程更加安全。

1.1 什么是 SSL/HTTPS

SSL(Secure Sockets Layer) 是一种安全协定，也就是说浏览器和网站共同遵守这个协定的话，那么在浏览网站时，传输的资料就会受到加密保护，增加骇客要偷走你们资料的难度，目前提到的 SSL 其实是 TLS(Transport Layer Security)，是 SSL 的进化版，但目前讲 SSL 都是指 TLS。

浏览器和网站的沟通可以透过 HTTP(port 80)、也可以透过 HTTPS(port 443)，这两个在于传输资料的安全性不同，现在的网站如果没有挂 HTTPS，通常浏览器都会警告使用者:「这是不安全的网站」，所以遵守 HTTPS 协定是目前的必备品了。

那 HTTPS 和 SSL 是什么关係 ?

要解释这点，需要先科普一下网路结构，一般来说网路分为五层(TCP/IP)或七层(OSI)，我们这边以七层来解释，HTTPS 在第七层-应用层(Application Layer)，而 SSL 在第六层-表达层(Presentation Layer) 进行加密、解密。

还想更深入了解的话，可以参考 [Security] SSL — HTTPS 背后的功臣 | Medium。

1.2 Django 怎么做到 SSL/HTTPS ?

Django 提供四个设定的步骤，就能将原本的 http 封包转向 https，详细需要设定的项目，参考官方文件，而详细该怎么让 Django 挂上 https，可以参考 Django部署HTTPS | 掘金。

2. Host header validation

2.1 什么是 Host header validation？

也就是 验证 header 内的 host 栏位，源自于 HTTP header injection 的 Host Header Attack，这个攻击简单来说，就是透过修改 HTTP request 中的 host 栏位，并且需配合 server 端有 Caching 机制时，把修改过的封包，暂存在 Cache Server 中，那其他不知情的使用者，就会从 Cache Server 抓到被污染(Poisoned)的封包。

那么被修改 host 栏位，会造成什么影响？

骇客可以把 host 改为自己的 server，然后改为执行某一支有危害的 javascript，严重性可以到作为钓鱼网站，只要能把 host 改为自己的 server 的话，就可能可以执行 上一篇所提到的 XSS 攻击。

2.2 Django 怎么做到 Host header validation？

要防止 Host header attack，就是 不要相信 从使用者发出 request 的栏位，而 Django 替开发者做的是，检查每个 request 的 host 栏位，是否有在 settings.py 中的 ALLOWED_HOSTS 里，但这个检查的功能，只有在你使用 django.http.HttpRequest.get_host() 这个 function 时，才会被检查，所以如果你不透过 get_host() 这个 function，来读取 request 中的 host 栏位，那么 Django 就帮不了你了。

还有一点，Django 预设把 X-Forwarded-Host 选项关掉，如果你要启用 X-Forwarded-Host 的 header 栏位的话，你必须要在 settings.py 中写下：

...USE_X_FORWARDED_HOST = True...

3. Referrer policy

3.1 什么是 Referrer policy ?

HTTP request 的 header 中，有一个栏位是 Referer，但其实正确的拼法是 Referrer，因为早期拼错了，所以沿用，这故事很瞎吧，竟然还被 wiki 给记录下来，总之他们两个是一样的东西，这个 Referer 的栏位，就是告诉后端 server 说：「我是从 referer 这个栏位的网站，连到你的网站的」，上图所显示的就是，我从 google 搜寻连到 iT 邦帮忙首页，所以 Referer 栏位就是 google。

而 Referrer policy 指的是，在传送 request 的时候，要放多少 referrer 的资讯在里头，可以详细放到是哪个 domain 的某个网页、也可以只放 domain、也可以什么都不放。

3.2 Django 的 Referrer policy？

Django 预设有的 SecurityMiddleware，你可以透过在 settings.py 设定 SECURE_REFERRER_POLICY 变数，来告诉 SecurityMiddleware 该怎么制定 Referrer policy，详细可以参考官方文件。

4. Session security

Session(会话)，你可以把它想成两个人之间的一次对话，两个人这次见面聊完了就算一个 Session 结束，而下次再见面就是不同的 Session，那么用在网路上，一个 Session 就是使用者造访了某一个网站，然后做了一些行为，可能是登入、结帐等等，都会记录在 Session 中。

4.1 什么是 Session security ?

例如攻击者可以利用 cookies 的机制，在一个正常的子网域底下正常登入，攻击者打下了另一个子网域，然后把这个攻击者登入的 cookies 传送给无辜的使用者，而使用者无意间就用了攻击者的帐号登入了，万一在这样的情况下，使用攻击者的帐号输入了自己重要的资讯，就被攻击者窃取成功。

听起来很绕口，参考官方文件举的例子应该会比较好懂 XD

4.2 Django 的 Session security ?

Django 预设有 SessionMiddleware，会帮你把使用者的 cookies 记录下来，cookies 包含了 session ID，会存在 DB 里的 django_session 表格中，详细的 session 可以参考官方文件。

5. User-uploaded content

简单来讲，就是不要相信使用者传上来的资料，作为一个称职的后端，必须好好检查从使用者接过来的资料、栏位或档案，从这两天的例子可以观察出，很多时候的安全漏洞，都是后端没有好好检查从使用者传来的资料发生的，像是 SQL Injection 就是没有检查资料、像 Host header attack 就是没有检查 host 栏位等等。

6. Additional security topics

官方列了六点，我大致翻译一下：

确保 python code 不是放在 web server 的 root注意任何使用者上传的档案Django 不会限制使用者验证的请求，为了防止被疯狂验证(被 authentication 的流量塞爆)，需要安装 plugin 或 server module 来限制在 settings.py 里的 SECRET_KEY 别外洩用防火墙来防御 Caching System 和 Database注意 OWASP 公布的前十危险的网站弱点

单日心得总结

终于把这系列文件 K 完了 QQ，也算是多学习好几种的攻击手法跟防御方法，还有框架能替开发者做的防护有哪些，K 完之后有点像是一个大补帖的概念，会瞬间觉得自己好像懂了点什么哈哈，可是实际在网安的概念都还是太弱了，继续加油～

明天就是这系列的最后一天了，想好好整理一下经过这三十天，从 Android 转学习后端的综合感想，以及未来的走向。

今天是礼拜四，好想工作室固定下午都有「想知道吗」的讲座，创办人 Howard 今天分享了一个主题：「自学的重要性」，提到设定学习目标有两种，一种是 加法 的目标设定，一种是 减法 的目标设定，像我在这系列所订定的目标就是属于 减法 类的，每写完一篇就扣一，直到写完三十篇就算完结，这种 减法 的目标有风险，因为你可能挑战完了，你就失去了目标，进而停止前进，明天的完结篇再来好好聊聊目标订定的哲学。

我是 RS，这是我的 不做怎么知道系列 文章，我们 明天见。

---

喜欢我的文章吗? 赶快来看看我都发了什么文章吧：我的文章目录欢迎阅读我的上一篇: [不做怎么知道系列之Android开发者的30天后端养成故事 Day28] - 你的Django安全吗?(上篇) #SecurityInDjango #XSS #CSRF欢迎阅读我的下一篇: [不做怎么知道系列之Android开发者的30天后端养成故事 Day30] - 结束是新的开始 #学到了什么? #下一步 #后端?iOS?Android?