隨著互聯(lián)網的普及，網絡安全變得越來越重要。Java等程序員需要掌握基本的web安全知識，防患于未然，下面列舉一些常見的安全漏洞，以及對應的防御解決方案。
成都創(chuàng)新互聯(lián)公司公司2013年成立，是專業(yè)互聯(lián)網技術服務公司，擁有項目網站設計、網站建設網站策劃，項目實施與項目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元山陽做網站,已為上家服務,為山陽各地企業(yè)和個人服務,聯(lián)系電話:028-86922220
1.前端安全
2.后端安全
1.XSS簡介
跨站腳本（cross site script）簡稱為XSS，是一種經常出現(xiàn)在web應用中的計算機安全漏洞，也是web中最主流的攻擊方式。
XSS是指惡意攻擊者利用網站沒有對用戶提交數據進行轉義處理或者過濾不足的缺點，進而添加一些代碼，嵌入到web頁面中去，使別的用戶訪問都會執(zhí)行相應的嵌入代碼。
2.XSS攻擊的危害
1、盜取用戶資料，比如：登錄帳號、網銀帳號等
2、利用用戶身份，讀取、篡改、添加、刪除企業(yè)敏感數據等
3、盜竊企業(yè)重要的具有商業(yè)價值的資料
4、非法轉賬
5、強制發(fā)送電子郵件
6、網站掛馬
7、控制受害者機器向其它網站發(fā)起攻擊
3.防止XSS解決方案
XSS的根源主要是沒完全過濾客戶端提交的數據 ，所以重點是要過濾用戶提交的信息。
1.CSRF簡介
CSRF（Cross-site request forgery）跨站請求偽造，也被稱為“One Click Attack”或者Session Riding，通?？s寫為CSRF或者XSRF，是一種對網站的惡意利用。
XSS利用站點內的信任用戶，而CSRF則通過偽裝來自受信任用戶的請求來利用受信任的網站。與XSS攻擊相比，CSRF更具危險性。
2.CSRF攻擊的危害
主要的危害來自于，攻擊者盜用了用戶身份，發(fā)送惡意請求。比如：模擬用戶的行為發(fā)送郵件，發(fā)消息，以及支付、轉賬等財產安全。
3.防止CSRF的解決方案
1.簡介
SQL注入是比較常見的網絡攻擊方式之一，主要是通過把SQL命令插入到Web表單遞交或輸入域名或頁面請求的查詢字符串，實現(xiàn)無帳號登錄，甚至篡改數據庫。
2.SQL注入的危害
3.防止SQL注入的方式
通常情況下，SQL注入的位置包括：
（1）表單提交，主要是POST請求，也包括GET請求；
（2）URL參數提交，主要為GET請求參數；
（3）Cookie參數提交；
（4）HTTP請求頭部的一些可修改的值，比如Referer、User_Agent等；
4.簡要舉例
舉一個簡單的例子,select * from user where id=100 ,表示查詢id為100的用戶信息，如果id=100變?yōu)?id=100 or 2=2,sql將變?yōu)椋簊elect * from user where id=100 or 2=2，將把所有user表的信息查詢出來，這就是典型的sql注入。
5.防止SQL注入的解決方案
1）對用戶的輸入進行校驗，使用正則表達式過濾傳入的參數
2）使用參數化語句，不要拼接sql，也可以使用安全的存儲過程
3）不要使用管理員權限的數據庫連接，為每個應用使用權限有限的數據庫連接
4）檢查數據存儲類型
5）重要的信息一定要加密
總之就是既要做好過濾與編碼并使用參數化語句，也要把重要的信息進行加密處理，這樣sql注入漏洞才能更好的解決。
以上就是Web安全介紹，更多Redis系列、Spring Cloud、Dubbo等微服務、MySQL數據庫分庫分表等架構設計，具體請參考：
回復關鍵詞 【高并發(fā)】即可獲?。?/p>
XSS攻擊通常是指黑客通過"HTML注入"篡改了網頁，插入了惡意的腳本，從而在用戶瀏覽網頁時，控制用戶瀏覽器的一種攻擊。
一、HttpOnly防止劫取Cookie
HttpOnly最早由微軟提出，至今已經成為一個標準。瀏覽器將禁止頁面的Javascript訪問帶有HttpOnly屬性的Cookie。目前主流瀏覽器都支持，HttpOnly解決是XSS后的Cookie支持攻擊。
我們來看下百度有沒有使用。
未登錄時的Cookie信息
可以看到，所有Cookie都沒有設置HttpOnly，現(xiàn)在我登錄下
發(fā)現(xiàn)在個叫BDUSS的Cookie設置了HttpOnly?？梢圆聹y此Cookie用于認證。
下面我用PHP來實現(xiàn)下：
?php
header("Set-Cookie: cookie1=test1;");
header("Set-Cookie: cookie2=test2;httponly",false);
setcookie('cookie3','test3',NULL,NULL,NULL,NULL,false);
setcookie('cookie4','test4',NULL,NULL,NULL,NULL,true);
?
script
alert(document.cookie);
/script
js只能讀到沒有HttpOnly標識的Cookie
二、輸入檢查
輸入檢查一般是檢查用戶輸入的數據中是否包含一些特殊字符，如、、'、"等，如果發(fā)現(xiàn)存在特殊字符，則將這些字符過濾或者編碼。
例如網站注冊經常用戶名只允許字母和數字的組合，或者郵箱電話，我們會在前端用js進行檢查，但在服務器端代碼必須再次檢查一次，因為客戶端的檢查很容易繞過。
網上有許多開源的“XSS Filter”的實現(xiàn)，但是它們應該選擇性的使用，因為它們對特殊字符的過濾可能并非數據的本意。比如一款php的lib_filter類：
$filter = new lib_filter();
echo $filter-go('1+11');
它輸出的是1，這大大歪曲了數據的語義，因此什么情況應該對哪些字符進行過濾應該適情況而定。
三、輸出檢查
大多人都知道輸入需要做檢查，但卻忽略了輸出檢查。
1、在HTML標簽中輸出
如代碼：
?php
$a = "scriptalert(1);/script";
$b = "img src=# onerror=alert(2) /";
?
div?=$b?/div
a href="#"?=$a?/a
這樣客戶端受到xss攻擊，解決方法就是對變量使用htmlEncode,php中的函數是htmlentities
?php
$a = "scriptalert(1);/script";
$b = "img src=# onerror=alert(2) /";
?
div?=htmlentities($b)?/div
a href="#"?=htmlentities($a)?/a
2、在HTML屬性中輸出
div id="div" name ="$var"/div
這種情況防御也是使用htmlEncode
在owasp-php中實現(xiàn)：
$immune_htmlattr = array(',', '.', '-', '_');
$this-htmlEntityCodec-encode($this-immune_htmlattr, "\"script123123;/script\"");
3、在script標簽中輸出
如代碼：
?php
$c = "1;alert(3)";
?
script type="text/javascript"
var c = ?=$c?;
/script
這樣xss又生效了。首先js變量輸出一定要在引號內，但是如果我$c = "\"abc;alert(123);//"，你會發(fā)現(xiàn)放引號中都沒用，自帶的函數都不能很好的滿足。這時只能使用一個更加嚴格的JavascriptEncode函數來保證安全——除數字、字母外的所有字符，都使用十六進制"\xHH"的方式進行編碼。這里我采用開源的owasp-php方法來實現(xiàn)
$immune = array("");
echo $this-javascriptCodec-encode($immune, "\"abc;alert(123);//");
最后輸出\x22abc\x3Balert\x28123\x29\x3B\x2F\x2F
4、在事件中輸出
a href="#" onclick="funcA('$var')" test/a
可能攻擊方法
a href="#" onclick="funcA('');alter(/xss/;//')"test/a
這個其實就是寫在script中，所以跟3防御相同
5、在css中輸出
在owasp-php中實現(xiàn)：
$immune = array("");
$this-cssCodec-encode($immune, 'background:expression(window.x?0:(alert(/XSS/),window.x=1));');
6、在地址中輸出
先確保變量是否是"http"開頭，然后再使用js的encodeURI或encodeURIComponent方法。
在owasp-php中實現(xiàn)：
$instance = ESAPI::getEncoder();
$instance-encodeForURL(‘url’);
四、處理富文體
就像我寫這篇博客，我?guī)缀蹩梢噪S意輸入任意字符，插入圖片，插入代碼，還可以設置樣式。這個時要做的就是設置好白名單，嚴格控制標簽。能自定義 css件麻煩事，因此最好使用成熟的開源框架來檢查。php可以使用htmlpurify
五、防御DOM Based XSS
DOM Based XSS是從javascript中輸出數據到HTML頁面里。
script
var x = "$var";
document.write("a href='"+x+"'test/a");
/script
按照三中輸出檢查用到的防御方法，在x賦值時進行編碼，但是當document.write輸出數據到HTML時，瀏覽器重新渲染了頁面，會將x進行解碼，因此這么一來，相當于沒有編碼，而產生xss。
防御方法：首先，還是應該做輸出防御編碼的，但后面如果是輸出到事件或腳本，則要再做一次javascriptEncode編碼，如果是輸出到HTML內容或屬性，則要做一次HTMLEncode。
會觸發(fā)DOM Based XSS的地方有很多：
document.write()、document.writeln()、xxx.innerHTML=、xxx.outerHTML=、innerHTML.replace、document.attachEvent()、window.attachEvent()、document.location.replace()、document.location.assign()
過濾特定符號pre t="code" l="java" public static String guolv(String a) {
a = a.replaceAll("%22", "");
a = a.replaceAll("%27", "");
a = a.replaceAll("%3E", "");
a = a.replaceAll("%3e", "");
a = a.replaceAll("%3C", "");
a = a.replaceAll("%3c", "");
a = a.replaceAll("", "");
a = a.replaceAll("", "");
a = a.replaceAll("\"", "");
a = a.replaceAll("'", "");
a = a.replaceAll("\\+", "");
a = a.replaceAll("\\(", "");
a = a.replaceAll("\\)", "");
a = a.replaceAll(" and ", "");
a = a.replaceAll(" or ", "");
a = a.replaceAll(" 1=1 ", "");
return a;
}
傳統(tǒng)防御技術
2.1.1基于特征的防御
傳統(tǒng)XSS防御多采用特征匹配方式，在所有提交的信息中都進行匹配檢查。對于這種類型的XSS攻擊，采用的模式匹配方法一般會需要對“javascript”這個關鍵字進行檢索，一旦發(fā)現(xiàn)提交信息中包含“javascript”，就認定為XSS攻擊。
2.1.2 基于代碼修改的防御
和SQL注入防御一樣，XSS攻擊也是利用了Web頁面的編寫疏忽，所以還有一種方法就是從Web應用開發(fā)的角度來避免：
1、對所有用戶提交內容進行可靠的輸入驗證，包括對URL、查詢關鍵字、HTTP頭、POST數據等，僅接受指定長度范圍內、采用適當格式、采用所預期的字符的內容提交，對其他的一律過濾。
2、實現(xiàn)Session標記(session tokens)、CAPTCHA系統(tǒng)或者HTTP引用頭檢查，以防功能被第三方網站所執(zhí)行。
3、確認接收的的內容被妥善的規(guī)范化，僅包含最小的、安全的Tag(沒有javascript)，去掉任何對遠程內容的引用(尤其是樣式表和javascript)，使用HTTP only的cookie。
當然，如上方法將會降低Web業(yè)務系統(tǒng)的可用性，用戶僅能輸入少量的制定字符，人與系統(tǒng)間的交互被降到極致，僅適用于信息發(fā)布型站點。
并且考慮到很少有Web編碼人員受過正規(guī)的安全培訓，很難做到完全避免頁面中的XSS漏洞。
擴展資料：
XSS攻擊的危害包括
1、盜取各類用戶帳號，如機器登錄帳號、用戶網銀帳號、各類管理員帳號
2、控制企業(yè)數據，包括讀取、篡改、添加、刪除企業(yè)敏感數據的能力
3、盜竊企業(yè)重要的具有商業(yè)價值的資料
4、非法轉賬
5、強制發(fā)送電子郵件
6、網站掛馬
7、控制受害者機器向其它網站發(fā)起攻擊
受攻擊事件
新浪微博XSS受攻擊事件
2011年6月28日晚，新浪微博出現(xiàn)了一次比較大的XSS攻擊事件。
大量用戶自動發(fā)送諸如：
“郭美美事件的一些未注意到的細節(jié)”，“建黨大業(yè)中穿幫地方”，“讓女人心動的100句詩歌”，“這是傳說中的神仙眷侶啊”等等微博和私信，并自動關注一位名為hellosamy的用戶。
事件的經過線索如下：
20:14，開始有大量帶V的認證用戶中招轉發(fā)蠕蟲
20:30，某網站中的病毒頁面無法訪問
20:32，新浪微博中hellosamy用戶無法訪問
21:02，新浪漏洞修補完畢
百度貼吧xss攻擊事件
2014年3月9晚，六安吧等幾十個貼吧出現(xiàn)點擊推廣貼會自動轉發(fā)等。并且吧友所關注的每個關注的貼吧都會轉一遍，病毒循環(huán)發(fā)帖。并且導致吧務人員，和吧友被封禁。
參考資料：
XSS攻擊-百度百科
防御方法
(1)基于特征的防御。XSS漏洞和著名的SQL注入漏洞一樣，都是利用了Web頁面的編寫不完善，所以每一個漏洞所利用和針對的弱點都不盡相同。這就給XSS漏洞防御帶來了困難，不可能以單一特征來概括所有XSS攻擊。
傳統(tǒng)的XSS防御在進行攻擊鑒別時多采用特征匹配方式，主要是針對“javascript”這個關鍵字進行檢索，但是這種鑒別不夠靈活，凡是提交的信息中各有“javascript”時，就被硬性的被判定為XSS攻擊。
(2)基于代碼修改的防御。Web頁面開發(fā)者在編寫程序時往往會出現(xiàn)一些失誤和漏洞，XSS攻擊正是利用了失誤和漏洞，因此一種比較理想的方法就是通過優(yōu)化Web應用開發(fā)來減少漏洞，避免被攻擊：1)用戶向服務器上提交的信息要對URL和附帶的的HTTP頭、POST數據等進行查詢，對不是規(guī)定格式、長度的內容進行過濾。2)實現(xiàn)Session標記（session tokens）、CAPTCHA系統(tǒng)或者HTTP引用頭檢查，以防功能被第三方網站所執(zhí)行。3)確認接收的的內容被妥善的規(guī)范化，僅包含最小的、安全的Tag（沒有javascript），去掉任何對遠程內容的引用（尤其是樣式表和javascript），使用HTTP only的cookie。
當然，如上操作將會降低Web業(yè)務系統(tǒng)的可用性，用戶僅能輸入少量的制定字符，人與系統(tǒng)間的交互被降到極致，僅適用于信息發(fā)布型站點。并且考慮到很少有Web編碼人員受過正規(guī)的安全培訓，很難做到完全避免頁面中的XSS漏洞。
(3)客戶端分層防御策略。客戶端跨站腳本攻擊的分層防御策略是基于獨立分配線程和分層防御策略的安全模型。它建立在客戶端(瀏覽器)，這是它與其他模型最大的區(qū)別，之所以客戶端安全性如此重要，客戶端在接受服務器信息，選擇性的執(zhí)行相關內容。這樣就可以使防御XSS攻擊變得容易，該模型主要由三大部分組成：（1）對每一個網頁分配獨立線程且分析資源消耗的“網頁線程分析模塊”；
（2）包含分層防御策略四個規(guī)則的用戶輸入分析模塊；
（3）保存互聯(lián)網上有關XSS惡意網站信息的XSS信息數據庫。
XSS攻擊主要是由程序漏洞造成的，要完全防止XSS安全漏洞主要依靠程序員較高的編程能力和安全意識，當然安全的軟件開發(fā)流程及其他一些編程安全原則也可以大大減少XSS安全漏洞的發(fā)生。這些防范XSS漏洞原則包括：
（1）不信任用戶提交的任何內容，對所有用戶提交內容進行可靠的輸入驗證，包括對URL、查詢關鍵字、HTTP頭、REFER、POST數據等，僅接受指定長度范圍內、采用適當格式、采用所預期的字符的內容提交，對其他的一律過濾。盡量采用POST而非GET提交表單；對“”，“；”，“””等字符做過濾；任何內容輸出到頁面之前都必須加以en-code，避免不小心把htmltag顯示出來。
（2）實現(xiàn)Session 標記（session tokens）、CAPTCHA（驗證碼）系統(tǒng)或者HTTP引用頭檢查，以防功能被第三方網站所執(zhí)行，對于用戶提交信息的中的img等link，檢查是否有重定向回本站、不是真的圖片等可疑操作。
（3）cookie 防盜。避免直接在cookie中泄露用戶隱私，例如email、密碼，等等；通過使cookie和系統(tǒng)IP綁定來降低cookie泄露后的危險。這樣攻擊者得到的cookie沒有實際價值，很難拿來直接進行重放攻擊。
（4）確認接收的內容被妥善地規(guī)范化，僅包含最小的、安全的Tag（沒有JavaScript），去掉任何對遠程內容的引用（尤其是樣式表和JavaScript），使用HTTPonly的cookie。
重慶分公司
重慶分公司
