中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

隨著前端技術(shù)的發(fā)展,安全問題已經(jīng)從服務(wù)器悄然來(lái)到了每一個(gè)用戶的的面前，盜取用戶數(shù)據(jù),制造惡意的可以自我復(fù)制的蠕蟲代碼,讓病毒在用戶間傳播,使服務(wù)器當(dāng)?shù)?更有甚者可能會(huì)在用戶不知覺得情況下,讓用戶成為攻擊者,這絕對(duì)不是駭人聽聞。富客戶端的應(yīng)用越來(lái)越廣，前端的安全問題也隨之增多,今天就簡(jiǎn)單介紹下一些常見的攻擊方式和預(yù)防攻擊辦法。

常見攻擊

1. XSS，跨站腳本攻擊(Cross Site Script) 。它指的是惡意攻擊者往Web頁(yè)面里插入惡意html代碼，當(dāng)用戶瀏覽該頁(yè)之時(shí)，嵌入的惡意html代碼會(huì)被執(zhí)行，從而達(dá)到惡意用戶的特殊目的。XSS屬于被動(dòng)式的攻擊，因?yàn)槠浔粍?dòng)且不好利用，所以許多人常呼略其危害性。但是隨著前端技術(shù)的不斷進(jìn)步富客戶端的應(yīng)用越來(lái)越多，這方面的問題越來(lái)越受關(guān)注。舉個(gè)簡(jiǎn)單例子 ： 假如你現(xiàn)在是sns站點(diǎn)上一個(gè)用戶，發(fā)布信息的功能存在漏洞可以執(zhí)行js 你在 此刻輸入一個(gè) 惡意腳本
2. CSRF(Cross Site Request Forgery)，跨站點(diǎn)偽造請(qǐng)求。顧名思義就是 通過偽造連接請(qǐng)求在用戶不知情的情況下，讓用戶以自己的身份來(lái)完成攻擊者需要達(dá)到的一些目的。csrf 的攻擊不同于xss csrf 需要被攻擊者的主動(dòng)行為觸發(fā)。這樣聽來(lái)似乎是有“被釣魚”的嫌疑哈哈。
   多窗口瀏覽器這這方面似乎是有助紂為虐的嫌疑，因?yàn)榇蜷_的新窗口是具有當(dāng)前所有會(huì)話的，如果是單瀏覽器窗口類似ie6 就不會(huì)存在這樣的問題，因?yàn)槊總€(gè)窗口都是一個(gè)獨(dú)立的進(jìn)程。舉個(gè)簡(jiǎn)單例子 ： 你正在玩白社會(huì)， 看到有人發(fā)了一個(gè)連接，你點(diǎn)擊過去，然后這個(gè)連接里面?zhèn)卧炝艘粋€(gè)送禮物的表單，這僅僅是一個(gè)簡(jiǎn)單的例子，問題可見一般。
3. cookie劫持，通過獲取頁(yè)面的權(quán)限，在頁(yè)面中寫一個(gè)簡(jiǎn)單的到惡意站點(diǎn)的請(qǐng)求，并攜帶用戶的cookie 獲取cookie后通過cookie 就可以直以被盜用戶的身份登錄站點(diǎn)。這就是cookie 劫持。舉個(gè)簡(jiǎn)單例子： 某人寫了一篇很有意思的日志，然后分享給大家，很多人都點(diǎn)擊查看并且分享了該日志，一切似乎都很正常，然而寫日志的人卻另有用心，在日志中偷偷隱藏了一個(gè)對(duì)站外的請(qǐng)求,那么所有看過這片日志的人都會(huì)在不知情的情況下把自己的cookie 發(fā)送給了 某人，那么他可以通過任意一個(gè)人的cookie 來(lái)登錄這個(gè)人的賬戶。

我們?cè)撛趺醋觯?/h2>

大致可以分為兩類 1 一般用戶 2網(wǎng)站開發(fā)人員。

• 首先我們來(lái)說說做為一個(gè)一般的web產(chǎn)品使用者，很多時(shí)候我們是被動(dòng)的，是在不知情的情況下被利用的。那么我們可以：
  1 對(duì)于安全級(jí)別較高的web應(yīng)用訪問 需要打開一個(gè)獨(dú)立瀏覽器窗口。
  2 對(duì)于陌生人發(fā)布的鏈接最好也是復(fù)制然后在新開的窗口中打開，當(dāng)然最好的辦法就是無(wú)視 – -。
• 對(duì)于開發(fā)人員來(lái)說我們得從相對(duì)詳細(xì)的一些角度來(lái)分析：
  對(duì)于xss 攻擊 特點(diǎn)是攻擊者的代碼必須能獲取用戶瀏覽器端的執(zhí)行權(quán)限，那么代碼是從哪里來(lái)的呢，想要杜絕此類攻擊出現(xiàn) 其實(shí)可以在入口 和出口 進(jìn)行嚴(yán)格的過濾，這樣的雙保險(xiǎn)應(yīng)當(dāng)說99% 的類似問題就被我們解決掉了，另外的1% 是那些蹩腳的瀏覽器帶來(lái)的后遺癥，相信在未來(lái)這種問題會(huì)越來(lái)越少的。

  這里我對(duì)xss漏洞的形式作了一些整理

  1. 惡意代碼值被作為某一標(biāo)簽的內(nèi)容顯示 （如果輸入的是html 則html會(huì)被解析）例如你輸入用戶名 更新后用戶名會(huì)顯示到頁(yè)面中的某一個(gè)標(biāo)簽內(nèi) 如果你輸入的是
     1. popper.w<script src=“hack.js“ type=“text/javajscript“></script>

     那么如果不做過濾直接顯示到頁(yè)面， 會(huì)引進(jìn)一個(gè)第三方的js 代碼并且會(huì)執(zhí)行。

     策略：在不需要html輸入的地方對(duì)html 標(biāo)簽 及一些特殊字符( ” < > & 等等 )做過濾，將其轉(zhuǎn)化為不被瀏覽器解釋執(zhí)行的字符

  2. 惡意代碼被作為某一標(biāo)簽的屬性顯示（通過用 “ 將屬性截?cái)鄟?lái)開辟新的屬性 或惡意方法） 這種情況往往是是開發(fā)人員為了實(shí)現(xiàn)功能可能會(huì)在某些dom標(biāo)簽上記錄一些用戶輸入的信息例如你輸入的用戶名 會(huì)在頁(yè)面中的標(biāo)簽中以 title 的形式出現(xiàn) 這時(shí)候 如果 你輸入的是精心設(shè)計(jì)的內(nèi)容 那么 看看 這個(gè)
     1. <a title=“popper.w“ onclick=“alert(1)“>popper.w“onclick=“alert(1)</a>

     這里我實(shí)際上輸入的內(nèi)容是“popper.w” onclick=”alert(1)”，當(dāng)然你可以在上邊寫更多的內(nèi)容。

     策略：對(duì)屬性中可能存在截?cái)嗟囊恍┳址M(jìn)行過濾 屬性本身存在的 單引號(hào)和雙引號(hào)都需要進(jìn)行轉(zhuǎn)碼。

  3. 惡意代碼被作為html代碼本身顯示 (常見的html編輯器) 這種情況存在的問題最多，不再這里舉例子了。策略：最好對(duì)用戶輸入的html 標(biāo)簽及標(biāo)簽屬性做白名單過濾，也可以對(duì)一些存在漏洞的標(biāo)簽和屬性進(jìn)行專門過濾。
  4. 惡意代碼被作為一段json字符串顯示 （通過 變量截?cái)?創(chuàng)造新的 惡意的js 變量 甚至是可執(zhí)行的代碼） 這個(gè)問題的關(guān)鍵是用戶輸入的信息可能會(huì)成為頁(yè)面中js 代碼的一部分。策略：對(duì)屬性中可能存在截?cái)嗟囊恍┳址M(jìn)行過濾 屬性本身存在的 單引號(hào)和雙引號(hào)都需要進(jìn)行轉(zhuǎn)碼。

  對(duì)于crsf 和cookie 劫持

  特點(diǎn) 隱蔽性比較高 有些時(shí)候是先利用xss 漏洞 然后再做 欺騙的

  策略
  通過 referer、token 或者 驗(yàn)證碼 來(lái)檢測(cè)用戶提交。
  盡量不要在頁(yè)面的鏈接中暴漏任何與用戶唯一號(hào)（用戶id）有關(guān)的信息。
  對(duì)于用戶修改 刪除 提交的操作最好都使用post 操作 。
  避免全站通用的cookie 嚴(yán)格的設(shè)置cookie的域。

ok 就寫到這里~

上邊講的都是一些比較常見的安全問題，主要是從js hack 方面來(lái)講的，隨著前端技術(shù)的不斷發(fā)展進(jìn)步，更多的安全問題可能會(huì)展現(xiàn)在我們面，對(duì)于開發(fā)者來(lái)說大多數(shù)的問題是可以在開發(fā)階段避免的，所以可怕的不是hack 可怕的是我們對(duì)自己的產(chǎn)品安全的松懈~。

來(lái)源：http://ued.sohu.com/article/446