Heim > Artikel > Backend-Entwicklung > yii2s vorbeugende Maßnahmen gegen CSRF-Angriffe
Dieser Artikel stellt hauptsächlich die vorbeugenden Maßnahmen gegen CSRF-Angriffe in yii2 vor. Jetzt kann ich ihn mit Ihnen teilen.
Heute wird Bruder Bei ihn bekannt machen Jeder. Was ist CSRF? Wenn Sie es bereits wissen, können Sie einfach zum Ende des Artikels scrollen und ihm ein „Gefällt mir“ geben.
CSRF (Cross-site request forgery) ist eine böswillige Nutzung von Websites und wurde 2007 in den Top 20 der Internet-Sicherheitsbedrohungen aufgeführt. Eine der versteckten Gefahren.
Über CSRF beginnen wir mit einer Geschichte~
Diese Geschichte beginnt damit, dass der Programmierer Lao Wang 10.000 Yuan verliert. Kurz gesagt: Das war es ein Dieb, aber es wurde vergeblich geborgen. Nachdem er das Geld verloren hatte, dachte Lao Wang immer wieder: Wie hat er das Geld verloren, warum hat er das Geld verloren, warum habe ich das Geld verloren~~
Später wurde es bei Lao Wang ernst psychologische Probleme. Beschlossen, sich an der Gesellschaft zu rächen.
Lao Wang studierte zunächst das Online-Banking-System und stellte fest, dass die Überweisung die Form GET
https://bank.abc.com/withdraw?account=liuxiaoer&amount=1000&to=abei
hatte. Das bedeutet, dass die 1.000 Yuan von liuxiaoer überwiesen wurden zu abei : Wenn die Anfrage den Bankserver erreicht, überprüft das Programm natürlich, ob die Anfrage von einer legitimen Sitzung stammt und der Benutzer der Sitzung liuxiaoer ist und sich angemeldet hat .
Lao Wang selbst hat auch ein Bankkonto wang2 Er hat versucht, sich einzuloggen und hat über den Browser eine Anfrage an die Bank gesendet. Der Code lautet wie folgt:
https://bank.abc.com/withdraw?account=liuxiaoer&amount=1000&to=wang2
fehlgeschlagen ~ Da das aktuelle Anmeldekonto Lao Wang selbst ist, stellte der Server nach dem Senden der Anfrage fest, dass der Benutzer wang2 und das Konto = liuxiaoer, zu denen die Sitzung gehörte, nicht dieselbe Person waren, und lehnten sie daher ab.
Mit anderen Worten, diese Operation muss von liuxiaoer selbst durchgeführt werden. Die Macht der Rache ist schrecklich. Lao Wang hat den liuxiaoer über Facebook gefunden. Dabei handelt es sich um die Bankkontonummer des Kuriers Herrn Liu.
So entstand ein großartiger Plan, Lao Wangs Plan sah so aus.
1. Erstellen Sie zunächst eine Webseite und fügen Sie der Webseite den folgenden Code hinzu
src="https://bank.abc.com/withdraw?account=liuxiaoer&amount=1000&to=wang2"
Lassen Sie dann Liu (liuxiaoer) diese Webseite in verschiedenen Szenarien besuchen.
2. Wenn Lao Liu (liuxiaoer) diese Webseite besucht, wird die obige Anfrage an die Bank gesendet und zu diesem Zeitpunkt werden natürlich auch die eigenen Browser-Cookie-Informationen von Lao Liu (liuxiaoer) übertragen Dies ist im Allgemeinen nicht der Fall. Dies gelingt jedoch nicht, da der Bankserver feststellt, dass Liu (liuxiaoer) nicht angemeldet ist.
3. Lao Wang dachte sich einen Trick aus. Er fand auf Taobao einen grauen Geschäftsmann, Lao Li, und bat ihn, verschiedene Methoden anzuwenden. Kurz gesagt, er bat Lao Liu (Liuxiaoer), Geld über das zu überweisen Browser.
4. Innerhalb von 2 Minuten nach dem dritten Schritt hat Lao Liu (liuxiaoer) erfolgreich gebeten, die von ihm erstellte Webseite erneut zu besuchen . Die Sitzung ist nicht abgelaufen. Nachdem die Webseite von Lao Wang eine Anfrage an den Bankserver gesendet hatte, war die Überprüfung erfolgreich.
5. Lao Wang erhielt die Zahlung nicht. Für die Bank war dies eine normale Überweisung.
Dies ist ein CSRF-Angriff und kann vom Browser nicht abgefangen werden.
Basierend auf der blutigen Geschichte oben fassen wir mehrere Merkmale von CSRF-Angriffen zusammen.
Hacker nutzen das Cookie des Opfers und andere Browserinformationen, um neue Benutzer des Servers zu täuschen. Der Hacker kann das Cookie usw. nicht erhalten.
Aufgrund der Same-Origin-Richtlinie des Browsers können Hacker nicht an die Antwortergebnisse des Angriffs gelangen. Sie können lediglich eine Anfrage stellen Kisten?
CSRF-Angriffe senden hauptsächlich Datenänderungsanfragen.
Was wir also schützen möchten, sind alle Clientanfragen, die Datenänderungen verursachen können, wie z. B. Neu, Aktualisierung und Löschung.
Basierend auf den Merkmalen von CSRF-Angriffen gibt es derzeit drei Hauptstrategien zur Abwehr von CSRF-Angriffen in der Branche:
Überprüfen Sie das HTTP-Referer-Feld.
Fügen Sie ein Token in der Anforderungsadresse hinzu und überprüfen Sie es.
Passen Sie das Attribut im HTTP-Header an und überprüfen Sie es .
Wenn Sie eine HTTP-Anfrage stellen, gibt es im Header ein Feld namens Referer, das die Quelladresse dieser Anfrage aufzeichnet. Daher kann der Server anhand der Frage, ob es sich in diesem Feld um denselben Domänennamen handelt, feststellen, ob die Anforderung zulässig ist, da der Referrer der von der eigenen Webseite des Clients initiierten Anforderung eine Hacker-Website ist.
Diese Methode ist die einfachste und erfordert keine Änderung des Geschäftscodes. Wir müssen lediglich jede am Server eintreffende Anfrage abfangen und analysieren.
Die Mängel dieser Methode liegen jedoch auch auf der Hand, da der Wert von Referer zum Browser gehört. Obwohl das HTTP-Protokoll keine Änderung zulässt, kann es dazu führen, dass der Browser selbst Lücken aufweist manuell eingestellt. Nicht sicher.
Zum Beispiel kann IE6 den Referrer-Wert durch Methoden manipulieren.
Diese Methode ist selbst in den neuesten Browsern nicht unbedingt verfügbar. Viele Benutzer stellen den Browser so ein, dass er den Referrer nicht bereitstellt. Möglicherweise handelt es sich hierbei um eine legitime Anfrage.
CSRF攻击之所以能成功,是因为黑客完全伪造了一次用户的正常请求(这也是浏览器无法拦截的原因),并且cookie信息就是用户自己的,那么我们如果在请求中放入一些黑客无法去伪造的信息(不存在与cookie中),不就可以抵御了么!
比如在请求前生成一个token放到session中,当请求发生时,将token从session拿出来和请求提交过来的token进行对比,如果相等则认证通过,否则拒绝。token时刻在变化,黑客无法去伪造。
针对于不同类型的请求一般方案是
GET 放到url中,比如http://url?csrftoken=xxxx
POST 放到表单的隐藏域
对于GET请求,这里有一点要说明,在一个网站中请求的url很多,一般情况我们是通过js对dom的所有节点进行遍历,发现a链接就在其href中增加token。
这里存在一个问题,比如黑客将自己网站的链接发到了要攻击页面,则黑客网站链接后面会有一个token,此刻客户可以通过编写自己网站代码得到这个token,然后用这个token立刻构造表单,发起CSRF攻击,因此在js遍历的时候,如果发现不是本站的链接,可以不加token。
这个方法在思路上和上面的token方式一样,只不过将token放到了HTTP头部中,不再参数传递,通过XMLHttpRequest类可以一次性的给所有请求加上csrftoken这个HTTP头属性并设置值。
这种方法适合上面批量添加token不方便的情况,一次性操作,不过局限性也比较大,XMLHttpRequest请求通常用在ajax方法中,并非所有请求都适合。
首先要说的是每种CSRF防范措施都有其弊端,无论你的防范多么严密,黑客拥有更多的攻击手段,因此在重要逻辑上(必须写入和删除)必须非常小心,接下来我们把yii2框架在csrf上的部署说一下。
我们以yii2.0.14为解说版本。
在CSRF这块,yii2框架采取了HTTP头部和参数token并行的方式,针对于每个请求,在beforeAction都会做一次判断,如下
// vendor/yiisoft/yii2/web/Controller.php public function beforeAction($action) { if (parent::beforeAction($action)) { if ($this->enableCsrfValidation && Yii::$app->getErrorHandler()->exception === null && !Yii::$app->getRequest()->validateCsrfToken()) { throw new BadRequestHttpException(Yii::t('yii', 'Unable to verify your data submission.')); } return true; } return false; }
如果我们没有设置 enableCsrfValidation 为false,并且没有报错,则会进行csrf验证,核心方法就是
Yii::$app->getRequest()->validateCsrfToken()
该方法存在于 vendor/yiisoft/yii2/web/Request.php 中,我们看一看它。
public function validateCsrfToken($clientSuppliedToken = null) { // 省略上面代码 return $this->validateCsrfTokenInternal($this->getBodyParam($this->csrfParam), $trueToken) || $this->validateCsrfTokenInternal($this->getCsrfTokenFromHeader(), $trueToken); }
validateCsrfToken函数代码我们只需要看最后的返回,getBodyParam或getCsrfTokenFromHeader方法得到的token,只要有一种验证通过,就认为合法。
以上是整体的思路,为了让你看的更清晰,我画一个图并增加一些名词解释。
以上是yii2的csrf策略部署,当然我还是推荐你使用 xdebug等调试工具 一步一步看看这个过程。
最后我在把上图的关键函数进行说明
generateCsrfToken() 该函数生成token并存到cookie或session中,该值不会随页面刷新而变化,它更多充当钥匙的作用,根绝它生成具体的csrfToken。
getCsrfToken() 生成具体的csrfToken,就是你在表单隐藏域中看到的那个值,这个值将来会传到服务器和真实的csrfToken进行对比,验证是否合法。
validateCsrfToken() 进行合法性验证,该函数得到一个真实的csrfToken然后和客户端上传来的csrfToken进行对比。
以上就是本文的全部内容,希望对大家的学习有所帮助,更多相关内容请关注PHP中文网!
相关推荐:
Das obige ist der detaillierte Inhalt vonyii2s vorbeugende Maßnahmen gegen CSRF-Angriffe. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!