完全不使用cookie是否就可以防御CSRF攻擊？你太天真了，不會(huì)告訴我你不能保護(hù)自己。讓我們看看什么是CSRF攻擊：CSRF跨站點(diǎn)請求偽造攻擊者盜用您的身份并以您的名義發(fā)送惡意請求。該請求對服務(wù)器完

完全不使用cookie是否就可以防御CSRF攻擊？

你太天真了，不會(huì)告訴我你不能保護(hù)自己。

讓我們看看什么是CSRF攻擊：CSRF跨站點(diǎn)請求偽造攻擊者盜用您的身份并以您的名義發(fā)送惡意請求。該請求對服務(wù)器完全合法，但它完成了攻擊者預(yù)期的操作，例如以您的名義發(fā)送電子郵件和消息、竊取您的帳號、添加系統(tǒng)管理員，甚至購買商品和轉(zhuǎn)移虛擬貨幣。

在這種攻擊中，一種是你說的客戶端攻擊，你的手機(jī)或電腦已經(jīng)保存了cookie，比如你正在瀏覽頭條新聞，黑客給你發(fā)了一個(gè)鏈接，仔細(xì)構(gòu)造了tweet，然后你可以點(diǎn)擊后自動(dòng)發(fā)送tweet。如果不將cookie保存在手機(jī)或電腦上，這種攻擊就無法實(shí)現(xiàn)。但如果鏈接的構(gòu)造比較巧妙，可以自動(dòng)點(diǎn)擊登錄，自動(dòng)保存cookie，那么你還是可以成功的。

另一種是服務(wù)器攻擊，您不保存cookie，但是許多服務(wù)器程序允許您使用會(huì)話來保持會(huì)話。餅干放在你的地方。無法修改會(huì)話。但這種攻擊具有及時(shí)性。您必須正在瀏覽網(wǎng)頁。例如，你在京東購物。此時(shí)，如果您點(diǎn)擊黑客發(fā)送的已構(gòu)建的京東鏈接，您將受到CSRF的攻擊。

因此，現(xiàn)在更安全的網(wǎng)站，如果它可以抵御CSRF，將讓cookie和會(huì)話同時(shí)使用，并使用httponly cookie。同時(shí)，它還將為您提供一系列由服務(wù)器用來驗(yàn)證的隨機(jī)令牌值。這樣，雖然黑客可以構(gòu)建惡意連接，但他們無法知道您的令牌值，因此自然無法攻擊您。

然而，近年來，由于大網(wǎng)站的業(yè)務(wù)不斷增長，為了方便用戶，很多網(wǎng)站往往稱同一個(gè)令牌值。例如，如果你在電腦上登錄標(biāo)題，悟空問答也會(huì)登錄。黑客會(huì)在這些不同的商業(yè)網(wǎng)站的通話中發(fā)現(xiàn)漏洞，并進(jìn)行令牌攻擊。

如果你真的想防守，你仍然需要以人為本，提高警惕。另外，我在標(biāo)題上寫了兩篇針對CSFR的攻擊，一篇是“零滲透學(xué)習(xí)網(wǎng)頁滲透第三課，首次體驗(yàn)CSRF漏洞”，一篇是“黑客毛毛黨技術(shù)披露支付寶紅包暴力與毛毛”，大家可以關(guān)注我，看看這兩篇文章，加深對CSRF的了解攻擊。

XSS與CSRF有什么區(qū)別嗎？

XSS是在不預(yù)先知道其他用戶頁面的代碼和數(shù)據(jù)包的情況下獲取信息。CSRF是代替用戶完成指定的動(dòng)作，需要知道其他用戶頁面的代碼和數(shù)據(jù)包。要完成CSRF攻擊，受害者必須依次完成兩個(gè)步驟：

登錄受信任的網(wǎng)站a并在本地生成cookie。

訪問危險(xiǎn)網(wǎng)站B而不注銷A。

CSRF防御

服務(wù)器端有許多CSRF方法，但總體思路是相同的，即在客戶端頁面上添加偽隨機(jī)數(shù)。通過驗(yàn)證碼的方法。

Flash，Django自己的web服務(wù)器是為開發(fā)而設(shè)計(jì)的，而不是為生產(chǎn)而設(shè)計(jì)的。它們都是web框架，而不是web服務(wù)器。它們自己的服務(wù)器只能是單個(gè)進(jìn)程。例如，gunicorn是一種預(yù)工作模式。每次從nginx發(fā)送請求時(shí)，它都會(huì)派生一個(gè)進(jìn)程來處理請求并緩沖相關(guān)數(shù)據(jù)。WSGI服務(wù)器是專門為生產(chǎn)環(huán)境開發(fā)的，可以對其進(jìn)行更多配置以處理更復(fù)雜的請求情況。在性能和穩(wěn)定性方面，它們更好。

使用了Gunicorn或者uWSGI，為什么還需要Nginx？

程序員編寫的代碼質(zhì)量可以從兩個(gè)方面入手

1。好的代碼通常很容易理解

專家總是把復(fù)雜的代碼變成簡單的代碼。他們寫的第一件事就是能讓人們理解。在提交代碼之前，谷歌和蘋果的工程師們會(huì)環(huán)顧四周，同時(shí)看到代碼。如果對方認(rèn)為沒有問題，可以直接提交，并在提交評論中寫上評審人的名字，這也承擔(dān)了責(zé)任，看似很簡單的模式，但大多數(shù)科技公司都采用這種模式。

所以代碼不能只被你自己理解，這樣其他人就可以理解你的想法和你的設(shè)計(jì)意圖。

2. 好的代碼，遵守整個(gè)系統(tǒng)的編碼規(guī)范，不出格，最重要的一點(diǎn)是好的代碼能經(jīng)得起實(shí)踐的檢驗(yàn)，在實(shí)際操作過程中，沒有大的系統(tǒng)崩潰才能被稱為好代碼

所以代碼不僅要好看，還需要有好的性能，對于程序員來說，代碼是面子，尤其是在團(tuán)隊(duì)合作中的應(yīng)用，一個(gè)人如果編寫出高質(zhì)量的代碼，就會(huì)給人一種可靠的感覺，在合作的過程中很容易形成一種默契的感覺。當(dāng)我們看到誰編寫了高質(zhì)量的代碼時(shí)，我們在調(diào)用模塊時(shí)會(huì)感到非常舒服和自在。代碼的好壞直接關(guān)系到程序員的素質(zhì)，有很多老程序員非常關(guān)心代碼的質(zhì)量，不允許自己犯一些非常低級的錯(cuò)誤，造成自己聲譽(yù)的損害。

如何判斷一個(gè)程序員寫代碼好與不好？

前端三項(xiàng)基本技能HTML、CSS、JS，不用說，這是前端吃飯的事。！TCP/IP、瀏覽器渲染原理、前端性能優(yōu)化與兼容性、PC/M開發(fā)、DOM、BOM、計(jì)算機(jī)原理（基本、通用軟件或計(jì)算機(jī)后臺都知道）等等！就目前的社會(huì)需求而言，除了基礎(chǔ)，一個(gè)或多個(gè)知識，如VUE，反應(yīng)，需要ng和節(jié)點(diǎn)。模糊地說，這已經(jīng)成為事實(shí)的標(biāo)準(zhǔn)，但你可以看到，所有這些知識都是JS。是的，都是JS。因此，掌握J(rèn)S的程度越高，學(xué)習(xí)這些框架就越容易。畢竟，這些都是API。

還有一些工具，如NPM、yarn、gulp和webpack。

大多數(shù)需求都是這樣的，團(tuán)隊(duì)的技術(shù)堆棧也圍繞著這些需求。但對于今年的學(xué)生其實(shí)要求不是那么高，基本掌握一般都不錯(cuò)。畢竟，團(tuán)隊(duì)知道今年學(xué)生的水平。我能有一個(gè)工作了三到五年的有經(jīng)驗(yàn)的司機(jī)嗎？不太可能。畢竟，許多事情需要通過項(xiàng)目來調(diào)整。