XSS：Cross-site Scripting
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted web sites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.
Also, it's crucial that you turn off HTTP TRACE support on all webservers. An attacker can steal cookie data via Javascript even when document.cookie is disabled or not supported on the client. This attack is mounted when a user posts a malicious script to a forum so when another user clicks the link, an asynchronous HTTP Trace call is triggered which collects the user's cookie information from the server, and then sends it over to another malicious server that collects the cookie information so the attacker can mount a session hijack attack. This is easily mitigated by removing support for HTTP TRACE on all webservers.
link：https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
解決方式：
1、后臺數據過濾關鍵標簽，Django中用mark_safe 顯示相關數據
2、前端數據用管道符+safe渲染。
CSRF （Cross-site Request-Forgery）：
official site:
https://en.wikipedia.org/wiki/Cross-site_request_forgery
Cross-site request forgery, also known as one-click attack or session riding and abbreviated as CSRF (sometimes pronounced sea-surf[1]) or XSRF, is a type of malicious exploit of a websitewhere unauthorized commands are transmitted from a user that the web application trusts.[2] There are many ways in which a malicious website can transmit such commands; specially-crafted image tags, hidden forms, and JavaScript XMLHttpRequests, for example, can all work without the user's interaction or even knowledge. Unlike cross-site scripting (XSS), which exploits the trust a user has for a particular site, CSRF exploits the trust that a site has in a user's browser.
本質上是防止從別的網站向自己網站發(fā)post請求, 客戶來訪問網站，網站會向客戶發(fā)送隨機字符串，然后客戶帶隨機字符串發(fā)送post請求
只有帶隨機字符串來，網站才認,一般是post請求才要求帶隨機字符串，其它網站第一次來不會帶隨機字符串。
如何防御？
首先服務器端要以某種策略生成隨機字符串，作為令牌(token)，保存在 Session 里。然后在發(fā)出請求的頁面，把該令牌以隱藏域一類的形式，與其他信息一并發(fā)出。在接收請求的頁面，把接收到的信息中的令牌與 Session 中的令牌比較，只有一致的時候才處理請求，處理完成后清理session中的值，否則返回 HTTP 403 拒絕請求或者要求用戶重新登陸驗證身份
