整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
客也搶賺加密貨幣挖礦財，去年開始出現大量的網頁式惡意挖礦程序，埋在熱門站點中利用用戶電腦資源挖礦，讓人防不勝防。不只是電腦，趨勢科技便指出，如果常覺得手機速度好像越來越慢或是電池常常發燙，可能已成為幫黑客的免費挖礦工。
網頁挖礦程序以Coinhive為首，色情類網站最危險
趨勢科技資深技術顧問簡勝財指出，過去惡意挖礦程序多以木馬程序的形式進駐在用戶電腦中偷挖礦，但從去年起，透過javascript執行的網頁式挖礦程序越來越多，甚至伴隨著惡意廣告大規模散布。12日也傳出包含英、美政府等4,200個網站，皆被植入惡意挖礦代碼。
什么是網頁式挖礦程序？以市占率最高的Coinhive為例，其將挖取門羅幣的程序打包在瀏覽器端的javascript中，而網站業者只要在自家網站嵌入Coinhive代碼，就能利用用戶電腦運算力挖取門羅幣。Coinhive希望網站業者可用這筆收入取代在網站植入廣告的收入，一方面也提高用戶體驗，而Coinhive則從中抽三成。
盡管Coinhive提醒不要在未提示用戶的情況下使用該服務，但事實上，Coinhive已經被多個網站濫用，偷偷盜取用戶電腦運算資源。根據AdGuard研究報告，有近十億名串流媒體網站的訪客被秘密地用在挖礦活動。
根據奇虎360旗下的網絡安全研究實驗室（Network Security Research Lab，Netlab）調查，Alexa Top 30萬的網站中，有629（0.21%）個網站在首頁嵌入挖礦代碼，其中色情相關站點是主體，占整體49%，其他還有詐騙（8%）、廣告（7%）、挖礦（7%）、影視（6%）等類別，且部分內容網站還會嵌入2個或更多挖礦網站。
挖礦程序不只是被嵌入在網頁中，趨勢科技發現，有黑客利用Google網絡廣告服務DoubleClick來散布挖礦惡意程序，也讓Coinhive挖礦程序數量突然成長3倍，受害地區包括日本、法國、臺灣、意大利與西班牙。
防堵網頁挖礦綁架，學會三招自保
趨勢科技指出，只要避免瀏覽器執行JavaScript應用程序，就能防止Coinhive挖礦程序使用CPU資源。此外，定期修補、定期更新軟件，尤其是網頁瀏覽器，也能降低加密貨幣挖礦程序的影響。
不只是電腦，手機同樣會受網頁式挖礦程序影響，但更難察覺。簡勝財建議，可用有網頁過濾機制的防毒應用程序加以防范。此外，趨勢科技也推出瀏覽器App「Trend Micro Zero」，可阻擋內嵌挖礦程序，降低裝置電量耗損，但目前僅有iOS版本。
習CSS注入的目的是學習計算機知識，千萬不要做違反法律的事情，不然等待你的是法律的嚴懲。
CSS僅僅只是一種用來表示樣式的語言嗎？當然不是！CSS就已被安全研究人員運用于滲透測試當中。使用屬性選擇器和iFrame，并通過CSS注入來竊取敏感數據的方法。但由于該方法需要iFrame，而大多數主流站點都不允許該操作，因此這種攻擊方法并不實用。這里為大家詳細介紹一種不需要iframe且只需10秒，就能為獲得CSRF token的方法。
一、背景
CSS屬性選擇器開發者可以根據屬性標簽的值匹配子字符串來選擇元素。 這些屬性值選擇器可以做以下操作：
屬性選擇器能讓開發人員查詢單個屬性的頁面HTML標記，并且匹配它們的值。一個實際的用例是將以“https://example.com”開頭的所有href屬性變為某種特定的顏色。而在實際環境中，一些敏感信息會被存放在HTML標簽內。在大多數情況下CSRF token都是以這種方式被存儲的：即隱藏表單的屬性值中。
可以將CSS選擇器與表單中的屬性進行匹配，并根據表單是否與起始字符串匹配，加載一個外部資源，例如背景圖片，來嘗試猜測屬性的起始字母。通過這種方式，攻擊者可以進行逐字猜解并最終獲取到完整的敏感數值。想要解決這個問題受害者可以在其服務器實施內容安全策略（CSP），防止攻擊者從外部加載CSS代碼。
二、無 iFrames
要做到無iFrame，使用一種方法：創建一個彈窗，然后在設置計時器后更改彈出窗口的位置。使用這種方仍然可以加載受害者的CSS，不再依賴于受害者是否允許iFrame。因為最初的彈出是通過用戶事件觸發的，沒有被瀏覽器阻止。為了強制重載，在CSS注入間彈出一個虛擬窗口，如下：
但由于CSRF是針對客戶端的攻擊，因此如果能想出一種不需要服務器的方法，那么就可以節省大量的開銷和簡化操作。為了接收客戶端加載資源，可以利用Service Workers來攔截和讀取請求數據。Service Workers目前只適用于同源請求，在演示中受害者和攻擊者頁面已處于同一源上。
不久后，chrome很可能會合并這個實驗性的功能，允許Service Workers攔截跨域請求。這樣，就可以確保在客戶端的攻擊100%的執行，并強制用戶在10秒內點擊鏈接執行CSRF攻擊，演示如下：
三、Demo
如上所述，因為不想運行一個web服務器，所以使用service workers攔截和模擬服務器端組件。目前，該演示只適用于Chrome瀏覽器。首先創建了一個易受攻擊的目標，它存在一個基于DOM的CSS注入漏洞，并在頁面放置了一個敏感token。再對腳本標簽添加了一些保護措施，對左尖括號和右尖括號進行了編碼。
接下來將強制加載受害者的CSS，并且使用上述方法，可一次竊取（猜解）一個敏感字符。在接收端，定義一個攔截請求的service worker，并通過post-message將它們發送回域，然后將token存儲在本地存儲中以供后續使用。你也可以想象一個后端Web服務器，通過Web套接字或輪詢將CSRF token回發給攻擊者域。
如果你的瀏覽器支持的話，只需點擊打開頁面任意位置，你將看到CSRF token將逐一被猜解出來。
四、結束語
反射型CSS注入實際上比存儲型CSS注入更致命，因為存儲型CSS注入需要一個服務器在受害者渲染之前來更新CSS。一段時間以來，CSS注入在嚴重程度上來回變化。過去IE瀏覽器是允許用戶在CSS中執行Javascript代碼的。這個演示也從某種程度上表明了CSS注入，以及渲染不受信任的CSS仍會導致嚴重的安全問題。所以在設計軟件一定要測試，才能及時發現和修復各種漏洞。
面我們說了 2 種常見的 Web 攻擊：XSS 和 SQL 注入。它們分別篡改了原始的 HTML 和 SQL 邏輯，從而使得黑客能夠執行自定義的功能。那么除了對代碼邏輯進行篡改，黑客還能通過什么方式發起 Web 攻擊呢？
我們還是先來看一個例子。在平常使用瀏覽器訪問各種網頁的時候，是否遇到過，自己的銀行應用突然發起了一筆轉賬，又或者，你的微博突然發送了一條內容？
在我們了解了 XSS 之后，你可能會聯想到，這是銀行或者微博中出現了某個 XSS 漏洞。但問題是，你今天并沒有訪問過銀行或者微博的頁面，所以并沒有“被 XSS”的機會。這時，你想到，會不會是你今天訪問的其他網頁里存在一些惡意的攻擊，實現了你不知道的轉賬和發博行為呢？
當我們在訪問一個 Web 頁面的時候，并不是我們自己去獲取頁面信息，而是瀏覽器去獲取了這些信息，并將它們進行了展示。這就說明，你允許瀏覽器代表你去和 Web 的服務端進行交互。為了能夠準確地代表你的身份，瀏覽器通常會在 Cookie 中存儲一些必要的身份信息。所以，在我們使用一個網頁的時候，只需要在首次訪問的時候登錄就可以了。
從用戶體驗上來說，這當然是非常方便的。但是，黑客正是利用這一點，來編寫帶有惡意 JavaScript 腳本的網頁，通過“釣魚”的方式誘導你訪問。然后，黑客會通過這些 JavaScript 腳本竊取你保存在網頁中的身份信息，通過仿冒你，讓你的瀏覽器發起偽造的請求，最終執行黑客定義的操作。而這一切對于你自己而言都是無感知的。這就是 CSRF（Cross-Site Request Forgery，跨站請求偽造）攻擊。
接下來，我們就以銀行轉賬為例子，來詳細講解一下這個攻擊過程。
當你在銀行頁面發起一筆轉賬時，這個過程其實是通過一個轉賬接口來完成的。這個接口的內容可能包括下面這些內容：
在轉賬之前，你肯定進行了一次登錄。這樣一來，這個轉賬接口就可以通過你之前存儲在 Cookie 中的相關字段來完成認證了。所以，這個接口參數中不需要包含任何身份認證相關的信息。也正是因為如此，這個接口滿足了 CSRF 攻擊的基本條件：
于是，黑客可以構造一個如下的空白網頁。我們假設這個網頁的地址為 hacker.com。
<html>
<body>
<form action="http://bank.com/transfer" method="POST">
<input type="hidden" name="to" value="hacker" />
<input type="hidden" name="amount" value="10000.00" />
</form>
<script>
document.forms[0].submit(); </script>
</body></html>在 HTML 中，<script>標簽內的 JavaScript 腳本會在打開網頁的時候自動執行。因此，一旦用戶訪問了這個 hacker.com 的頁面，它就會自動提交 form 表單，向http://bank.com/transfer這個接口（假設為轉賬接口）發起一個 POST 請求。
其中，to 和 amount 這兩個參數，代表著用戶向黑客的賬號轉賬 10000 元。只要這個用戶之前登錄過 bank.com，并且賬戶余額大于 10000 元，那么黑客就能夠成功地收到這 10000 元的轉賬了。在這個網頁中，<input>的標簽帶有“hidden”屬性，所以這整個過程對于用戶來說都是不可見的。如下圖所示：
和 XSS 一樣，CSRF 也可以仿冒用戶去進行一些功能操作的請求，比如修改密碼、轉賬等等，相當于繞過身份認證，進行未授權的操作。
值得一提的是，盡管黑客通過 CSRF 能進行的操作沒有 XSS 豐富，但 CSRF 在傳播和攻擊成本上都低于 XSS。這也就是說，即使你的網頁中沒有任何注入漏洞，但只要接口配置不當，就能夠被 CSRF 利用。而黑客也只需要在自己的域名中，搭建一個誘導性的網頁，就可以讓任何訪問網頁的用戶都遭受到 CSRF 攻擊。而且，用戶每天需要訪問大量的網頁，根本沒有辦法確認每一個網頁的合法性。而從嚴格意義上來說，用戶根本沒有辦法防止 CSRF 攻擊。因此，我們只能從應用本身入手去加強防護。
那究竟該怎么進行 CSRF 防護呢？我們有兩種方法。
我們知道，CSRF 是通過自動提交表單的形式來發起攻擊的。所以，在前面轉賬的例子中，黑客可以通過抓包分析出 http://bank.com/transfer 這個接口所需要的參數，從而構造對應的 form 表單。因此，我們只需要在這個接口中，加入一個黑客無法猜到的參數，就可以有效防止 CSRF 了。這就是 CSRF Token 的工作原理。它的工作流程如下圖所示：
因為 CSRF Token 是每次用戶正常訪問頁面時，服務端隨機生成返回給瀏覽器的。所以，每一次正常的轉賬接口調用，都會攜帶不同的 CSRF Token。黑客沒有辦法進行提前猜測，也就沒有辦法構造出正確的表單了。
回想一下，當你進行各類支付操作的時候，銀行網頁通常會要求你輸入支付密碼。你可能會覺得奇怪，明明自己已經登錄了，為什么還需要輸入一個獨立的支付密碼呢？這其實和 CSRF Token 的原理一樣：這個獨立的支付密碼是需要用戶輸入的，只存在于用戶的記憶中，因此，也是黑客無法獲取到的參數。
怎么理解呢？假如說，黑客通過 CSRF 攻擊，替你發起了一筆轉賬。在支付的時候，銀行會發起一個全新的頁面，讓你驗證支付密碼。這個時候你發現，這個支付請求不是你本人發起的，那你肯定不會輸入支付密碼來完成驗證。所以，在用戶進行支付這樣的敏感操作時，應用通常會要求用戶提供一些私密的信息，就是為了對 CSRF 攻擊進行防護。
你現在對 CSRF 的攻擊和防護，應該有了一個大概的了解。簡單來說，CSRF 其實就是黑客利用瀏覽器存儲用戶 Cookie 這一特性，來模擬用戶發起一次帶有認證信息的請求，比如轉賬、修改密碼等。防護 CSRF 的原理也很簡單，在這些請求中，加入一些黑客無法得到的參數信息即可，比如 CSRF Token 或者獨立的支付密碼等。掌握了這些內容，其實 CSRF 的知識基本上就差不多了。
在 CSRF 中，黑客通過誘導用戶訪問某個網站，讓用戶的瀏覽器發起一個偽造的請求。那么，如果服務端發起了這個偽造的請求，又會發生什么呢？
我們知道，服務端也有代理請求的功能：用戶在瀏覽器中輸入一個 URL（比如某個圖片資源），然后服務端會向這個 URL 發起請求，通過訪問其他的服務端資源來完成正常的頁面展示。
這個時候，只要黑客在輸入中提交一個內網 URL，就能讓服務端發起一個黑客定義的內網請求，從而獲取到內網數據。這就是 SSRF（Server Side Request Forgery，服務端請求偽造）的原理。而服務端作為內網設備，通常具備很高的權限，所以，這個偽造的請求往往因為能繞過大部分的認證和授權機制，而產生很嚴重的后果。
比方說，當我們在百度中搜索圖片時，會涉及圖片的跨域加載保護，百度不會直接在頁面中加載圖片的源地址，而是將地址通過 GET 參數提交到百度服務器，然后百度服務器請求到對應的圖片，再返回到頁面展示出來。
這個過程中，百度服務器實際上會向另外一個 URL 地址發起請求（比如，上圖中的http://s1.sinaimg.cn）。利用這個代理發起請求的功能，黑客可以通過提交一個內網的地址，實現對內網任意服務的訪問。這就是 SSRF 攻擊的實現過程，也就是我們常說的“內網穿透”。
了解了 SSRF 攻擊的過程之后，我們知道，在服務端不做任何保護措施的情況下，黑客可以利用 SSRF 向內網發起任意的 HTTP 請求。那么，這些請求會產生什么樣的后果呢？我總結了一下，主要會有這樣兩種動作：內網探測和文件讀取。
內外網一般是隔離的。所以，黑客在外網環境中，是無法知道內網有哪些服務器，這些服務器又分別提供了哪些服務。但是，通過一個加載圖片的 SSRF 漏洞，黑客就能夠對內網進行探測。這是怎么做到的呢？別著急，我們慢慢來看。
在前面百度搜圖的例子中，我們請求的地址是：https://image.baidu.com/search/detail?objurl=http://s1.sinaimg.cn/picture.jpg。因為http://s1.sinaimg.cn/picture.jpg會正常返回一個圖片，所以網頁會展示出來對應的圖片。
我們假定這樣一個服務端邏輯：在這個請求過程中，服務端會判斷 objurl 返回數據的 Content Type 是否為 image/jpeg。那么，可能的返回結果就有三種：
基于這三種返回邏輯，黑客可以構造一個惡意的請求地址：https://image.baidu.com/search/detail?objurl=127.0.0.1:3306。如果服務器返回“格式錯誤”，則代表服務端本地的 3306 端口可用；如果返回“找不到圖片”，則代表不可用。我們知道，3306 是 MySQL 對應的端口號，因此，根據這個返回的信息，黑客就能夠知道服務端本地是否開啟了一個 MySQL 服務。接下來，黑客只需要不斷重復這個過程，嘗試不同的 IP 和端口號，就能夠一點一點探測出整個內網的結構。
服務器除了對圖片的代理不做合法性判斷之外，對很多其他的代理也不做判斷，而是直接將代理的結果返回到前端。我們稱這種情況為“有回顯的 SSRF”。在這種情況下，黑客不僅能夠知道請求是否成功了，還能夠知道具體返回的內容。這時候你肯定會好奇，黑客究竟是怎么做到呢？
在 URI 中，開頭的 http:// 和 https:// 代表需要使用什么協議去進行請求。除了 HTTP 之外，URI 還有很多種協議可以選擇，比如 file:// 就是直接讀取本地的文件。通過輸入 file://etc/passwd，黑客就能夠通過一個請求獲取到本地的 passwd 文件，從而知道本地有哪些用戶。經過不斷地嘗試，黑客就能夠把整個服務器中的文件內容都給拉取出來，這其中包括密鑰、源碼等極度敏感的信息。
一般情況下，黑客會通過 SSRF 攻擊拿到了服務端的源碼，然后通過對源碼的分析，找到了一個 SQL 注入的漏洞，再利用 SSRF 發起對內網的 SQL 注入攻擊，從而拿到了內網的命令執行權限。
因為 SSRF 漏洞起源于業務的正常功能需求（比如百度圖片的圖片請求等等）。因此，我們很難真正消除它。盡管如此，我還是會為你介紹幾種常見的防護手段，來盡可能地提高應用的安全性。這些常見的手段主要包括：白名單限制、協議限制和請求端限制。
白名單的限制永遠是最簡單、最高效的防護措施。SSRF 中的白名單，就是對用戶提交上來的目標 URL 進行限制。比如，只允許是同一個域名下的 URL。你可以理解為，讓百度圖片的代理服務只允許代理 baidu.com 的 URL。但是，很多時候，因為業務功能的設計，白名單的限制并不可行。比如，上述百度圖片的例子，這個功能的設計思路就是，baidu.com 這個域名下能夠請求各類域名下的圖片資源（比如上述例子中的 sinaimg.cn）。
在這種時候，我們可以對協議和資源類型等進行限制。比如：對于使用協議，我們只允許 HTTP 或者 HTTPS 協議；對于返回的內容，我們只允許圖片格式的內容。通過這些限制，雖然不能完全阻止黑客發起 SSRF 攻擊，但也大大降低了黑客能夠造成的危害。
除此之外，因為 SSRF 最終的結果，是接受代理請求的服務端發生數據泄漏。所以，SSRF 防護不僅僅涉及接收 URL 的服務端檢測，也需要接受代理請求的服務端進行配合。在這種情況下，我們就需要用到請求端限制，它的防護措施主要包括兩個方面。
第一，為其他業務提供的服務接口盡量使用 POST，避免 GET 的使用。因為，在 SSRF 中（以及大部分的 Web 攻擊中），發起一個 POST 請求的難度是遠遠大于 GET 請求的。因為默認的請求方式是 GET，而發起 POST 請求，需要在發起 HTTP 請求的時候進行配置。很多安全漏洞中不包含能夠配置協議的地方。在上述百度圖片的例子中，黑客顯然就只能發起 GET 請求。如果某個敏感服務是 POST 的，黑客就無法請求到相關資源了。
第二，為其他業務提供的服務接口，最好每次都進行驗證。通過 SSRF，黑客只能發起請求，并不能獲取到服務端存儲的驗證信息（如認證的 key 和 secret 等）。因此，只要接受代理請求的端對每次請求都進行完整的驗證，黑客無法成功通過驗證，也就無法完成請求了。
我們介紹了 CSRF 和 SSRF 這兩種攻擊方式。其中，CSRF 是黑客控制用戶的瀏覽器發起偽造的請求，SSRF 則是黑客控制服務端發起偽造的請求。通過偽造的請求，黑客可以偽造用戶或者服務器的身份，越權獲取數據或者發起請求。應用中的請求接口越敏感，黑客能夠造成的傷害就越大。
除此之外，CSRF 和 SSRF 產生于正常的業務功能邏輯中，因此，我們沒有辦法從根本上組織黑客發起偽造的請求。但是，你可以通過加強接口的安全驗證，來避免偽造請求造成影響。在 CSRF 中，我們可以通過 CSRF Token 或者二次驗證等操作來加強防護。這樣，黑客無法獲取到隱私信息，也就無法發起連續的請求了。在 SSRF 中，我們則需要限制可請求的域名，來限制黑客能夠訪問到的資源。另外，目標服務端，也需要加強接口的驗證，來避免偽造請求成功通過授權。
*請認真填寫需求信息，我們會在24小時內與您取得聯系。
