⑴ 求大神講講web安全,nodejs怎麼防止跨域攻擊和sql注入
是CSRF(Cross-site request forgery) 不是你寫的那個!
跨域不用擔心.主流瀏覽器都會幫你做防禦的. 問題不大,主要是你自己別給其他域的許可權即可.非必要的話,以最小許可權原則.
xss主要就是過濾輸入輸出.如果業務很多,還是找人審計代碼吧.或者用比較成熟的模塊.CSRF的話,1,驗證來源 2加隨機token之類的.
sqli主要還是過濾輸入的地方.過濾/轉義關鍵字比如select,and,or等等(有專門的防注入模塊).覺得怕麻煩的話.用那些雲主機的防禦功能.再加個cdn基本就沒事了.(對於一般的反射型跨站也適用)
⑵ web.config 跨域問題
一、認識Web.config文件
Web.config文件是一個XML文本文件,它用來儲存 ASP.NET Web 應用程序的配置信息(如最常用的設置ASP.NET Web 應用程序的身份驗證方式),它可以出現在應用程序的每一個目錄中。當你通過VB.NET新建一個Web應用程序後,默認情況下會在根目錄自動創建一個默認的
Web.config文件,包括默認的配置設置,所有的子目錄都繼承它的配置設置。如果你想修改子目錄的配置設置,你可以在該子目錄下新建一個Web.config文件。它可以提供除從父目錄繼承的配置信息以外的配置信息,也可以重寫或修改父目錄中定義的設置。
在運行時對Web.config文件的修改不需要重啟服務就可以生效(註:<processModel> 節例外)。當然Web.config文件是可以擴展的。你可以自定義新配置參數並編寫配置節處理程序以對它們進行處理。
二、web.config配置文件(默認的配置設置)以下所有的代碼都應該位於
<configuration>
<system.web>
和
</system.web>
</configuration>
之間,出於學習的目的下面的示例都省略了這段XML標記
1、<authentication> 節
作用:配置 ASP.NET 身份驗證支持(為Windows、Forms、PassPort、None四種)。該元素只能在計算機、站點或應用程序級別聲明。<authentication> 元素必需與<authorization> 節配合使用。
示例:
以下示例為基於窗體(Forms)的身份驗證配置站點,當沒有登陸的用戶訪問需要身份驗證的網頁,網頁自動跳轉到登陸網頁。
<authentication mode="Forms" >
<forms loginUrl="logon.aspx" name=".FormsAuthCookie"/>
</authentication>
其中元素loginUrl表示登陸網頁的名稱,name表示Cookie名稱
2、<authorization> 節
作用:控制對 URL 資源的客戶端訪問(如允許匿名用戶訪問)。此元素可以在任何級別(計算機、站點、應用程序、子目錄或頁)上聲明。必需與<authentication> 節配合使用。
示例:以下示例禁止匿名用戶的訪問
<authorization>
<deny users="?"/>
</authorization>
註:你可以使用user.identity.name來獲取已經過驗證的當前的用戶名;可以使用
web.Security.FormsAuthentication.RedirectFromLoginPage方法將已驗證的用戶重定向到用戶剛才請求的頁面.具體的實例請參考:
Forms驗證 http://www.fanvb.net/websample/dataauth.aspx
3、<compilation>節
作用:配置 ASP.NET 使用的所有編譯設置。默認的debug屬性為「True」.在程序編譯完成交付使用之後應將其設為True(Web.config文件中有詳細說明,此處省略示例)
4、<customErrors>
作用:為 ASP.NET 應用程序提供有關自定義錯誤信息的信息。它不適用於 XML Web services 中發生的錯誤。
示例:當發生錯誤時,將網頁跳轉到自定義的錯誤頁面。
<customErrors defaultRedirect="ErrorPage.aspx" mode="RemoteOnly">
</customErrors>
其中元素defaultRedirect表示自定義的錯誤網頁的名稱。mode元素表示:對不在本地 Web 伺服器上運行的用戶顯示自定義(友好的)信息。
5、<httpRuntime>節
作用:配置 ASP.NET HTTP 運行庫設置。該節可以在計算機、站點、應用程序和子目錄級別聲明。
示例:控制用戶上傳文件最大為4M,最長時間為60秒,最多請求數為100
<httpRuntime maxRequestLength="4096" executionTimeout="60" appRequestQueueLimit="100"/>
6、 <pages>
作用:標識特定於頁的配置設置(如是否啟用會話狀態、視圖狀態,是否檢測用戶的輸入等)。<pages>可以在計算機、站點、應用程序和子目錄級別聲明。
示例:不檢測用戶在瀏覽器輸入的內容中是否存在潛在的危險數據(註:該項默認是檢測,如果你使用了不檢測,一要對用戶的輸入進行編碼或驗證),在從客戶端回發頁時將檢查加密的視圖狀態,以驗證視圖狀態是否已在客戶端被篡改。(註:該項默認是不驗證)
<pages buffer="true" enableViewStateMac="true" validateRequest="false"/>
7、<sessionState>
作用:為當前應用程序配置會話狀態設置(如設置是否啟用會話狀態,會話狀態保存位置)。
示例:
<sessionState mode="InProc" cookieless="true" timeout="20"/>
</sessionState>
註:
mode="InProc"表示:在本地儲存會話狀態(你也可以選擇儲存在遠程伺服器或SAL伺服器中或不啟用會話狀態)
cookieless="true"表示:如果用戶瀏覽器不支持Cookie時啟用會話狀態(默認為False)
timeout="20"表示:會話可以處於空閑狀態的分鍾數
8、<trace>
作用:配置 ASP.NET 跟蹤服務,主要用來程序測試判斷哪裡出錯。
示例:以下為Web.config中的默認配置:
<trace enabled="false" requestLimit="10" pageOutput="false" traceMode="SortByTime" localOnly="true" />
註:
enabled="false"表示不啟用跟蹤;requestLimit="10"表示指定在伺服器上存儲的跟蹤請求的數目
pageOutput="false"表示只能通過跟蹤實用工具訪問跟蹤輸出;
traceMode="SortByTime"表示以處理跟蹤的順序來顯示跟蹤信息
localOnly="true" 表示跟蹤查看器 (trace.axd) 只用於宿主 Web 伺服器
三、自定義Web.config文件配置節
自定義Web.config文件配置節過程分為兩步。
一是在在配置文件頂部 <configSections> 和 </configSections>標記之間聲明配置節的名稱和處理該節中配置數據的 .NET Framework 類的名稱。
二是在 <configSections> 區域之後為聲明的節做實際的配置設置。
示例:創建一個節存儲資料庫連接字元串
<configuration>
<configSections>
<section name="appSettings" type="System.Configuration.NameValueFileSectionHandler, System, Version=1.0.3300.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"/>
</configSections>
<appSettings>
<add key="scon" value="server=a;database=northwind;uid=sa;pwd=123"/>
</appSettings>
<system.web>
......
</system.web>
</configuration>
四、訪問Web.config文件
你可以通過使用ConfigurationSettings.AppSettings 靜態字元串集合來訪問 Web.config 文件示例:獲取上面例子中建立的連接字元串。
Dim sconstr As String = ConfigurationSettings.AppSettings("SconStr")
Dim scon = New SqlConnection(sconstr)
⑶ 如何用webpack解決跨域問題
匯編主要是要了解CPU指令及用法,常說的是PC機的x86匯編,指令是x86的復雜指令集。
arm匯編是arm的精簡指令集,比x86容易學,程序格式倒是和x86匯編差不多。
C語言ARM的和x86的差不多,除了對硬體寄存器操作不同,其它語法和流程都一樣。
arm匯編程序每一行是指定arm core執行一條指令,每條指令都是硬體相關。
如:LDR R3, #1 ;用LDR指令將數值1放入R3寄存器准備參與運算
C語言與arm指令無關,只與邏輯運算有關,指定硬體地址的操作才與硬體相關;
如果用arm編譯器來編譯,每行可能編譯出1到多條arm指令。
⑷ 手機APP和web服務端 跨域問題
跨域問題來源於JavaScript的同源策略,即只有 協議+主機名+埠號 (如存在)相同,則允許相互訪問。也就是說JavaScript只能訪問和操作自己域下的資源,不能訪問和操作其他域下的資源。
在以前,前端和後端混雜在一起, 比如JavaScript直接調用同系統裡面的一個Httphandler,就不存在跨域的問題,但是隨著現代的這種多種客戶端的流行,比如一個應用通常會有Web端,App端,以及WebApp端,各種客戶端通常會使用同一套的後台處理邏輯,即API, 前後端分離的開發策略流行起來,前端只關注展現,通常使用JavaScript,後端處理邏輯和數據通常使用WebService來提供json數據。一般的前端頁面和後端的WebService API通常部署在不同的伺服器或者域名上。這樣,通過ajax請求WebService的時候,就會出現同源策略的問題。
需要說明的是,同源策略是JavaScript裡面的限制,其他的編程語言,比如在C#,Java或者iOS等其他語言中是可以調用外部的WebService,也就是說,如果開發Native應用,是不存在這個問題的,但是如果開發Web或者Html5如WebApp,通常使用JavaScript ajax對WebService發起請求然後解析返回的值,這樣就可能存在跨域的問題。
一般的,很容易想到,將外部的資源搬到同一個域上就能解決同源策略的限制的。即在Web網站上同時開發一個Http服務端頁面,所有JavaScript的請求都發到這個頁面上來,這個頁面在內部使用其他語言去調用外部的WebService。即添加一個代理層。這種方式可以解決問題,但是不夠直接和高效。
目前,比較常見的跨域解決方案包括JSONP (JSON with padding)和CORS (Cross-origin resource sharing )。一些解決方案需要客戶端和服務端配合如JSOP,一些則只需要服務端配合處理比如CORS。下面分別介紹這兩種跨域方案,以及服務端WebService如何支持這兩種跨域方案。
JSONP以及WebService的支持
同源策略下,某個伺服器是無法獲取到伺服器以外的數據,但是html裡面的img,iframe和script等標簽是個例外,這些標簽可以通過src屬性請求到其他伺服器上的數據。而JSONP就是通過script節點src調用跨域的請求。
當我們向伺服器提交一個JSONP的請求時,我們給服務傳了一個特殊的參數,告訴服務端要對結果特殊處理一下。這樣服務端返回的數據就會進行一點包裝,客戶端就可以處理。
舉個例子,服務端和客戶端約定要傳一個名為callback的參數來使用JSONP功能。比如請求的參數如下:
http://www.example.net/sample.aspx?callback=mycallback
如果沒有後面的callback參數,即不使用JSONP的模式,該服務的返回結果可能是一個單純的json字元串,比如:
{ foo : 'bar' }
如果和服務端約定jsonp格式,那麼服務端就會處理callback的參數,將返回結果進行一下處理,比如處理成:
mycallback({ foo : 'bar' })
可以看到,這其實是一個函數調用,比如可以實現在頁面定義一個名為mycallback的回調函數:
mycallback = function(data)
{
alert(data.foo);
};
現在,請求的返回值回去觸發回調函數,這樣就完了了跨域請求。
如果使用ServiceStack創建WebService的話,支持Jsonp方式的調用很簡單,只需要在AppHost的Configure函數裡面注冊一下對響應結果進行過濾處理即可。
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
ResponseFilters.Add((req, res, dto) =>
{
var func = req.QueryString.Get("callback");
if (!func.isNullOrEmpty())
{
res.AddHeader("Content-Type", ContentType.Html);
res.Write("<script type='text/javascript'>{0}({1});</script>"
.FormatWith(func, dto.ToJson()));
res.Close();
}
});
}
JSONP跨域方式比較方便,也支持各種較老的瀏覽器,但是缺點很明顯,他只支持GET的方式提交,不支持其他Post的提交,Get方式對請求的參數長度有限制,在有些情況下可能不滿足要求。所以下面就介紹一下CORS的跨域解決方案。
CORS跨域及WebService的支持
先來看一個例子,我們新建一個基本的html頁面,在裡面編寫一個簡單的是否支持跨域的小腳本,如下:
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>AJAX跨域請求測試</title>
</head>
<body>
<input type='button' value='開始測試' onclick='crossDomainRequest()' />
<div id="content"></div>
<script type="text/javascript">
//<![CDATA[
var xhr = new XMLHttpRequest();
var url = 'http://localhost:8078/json/ShopUserLogin';
function crossDomainRequest() {
document.getElementById("content").innerHTML = "開始……";
if (xhr) {
xhr.open('POST', url, true);
xhr.onreadystatechange = handler;
xhr.send();
} else {
document.getElementById("content").innerHTML = "不能創建 XMLHttpRequest";
}
}
function handler(evtXHR) {
if (xhr.readyState == 4) {
if (xhr.status == 200) {
var response = xhr.responseText;
document.getElementById("content").innerHTML = "結果:" + response;
} else {
document.getElementById("content").innerHTML = "不允許跨域請求。";
}
}
else {
document.getElementById("content").innerHTML += "<br/>執行狀態 readyState:" + xhr.readyState;
}
}
//]]>
</script>
</body>
</html>
然後保存為本地html文件,可以看到,這個腳本中,對本地的服務http://localhost:1337/json/Hello 發起了一個請求, 如果使用chrome 直接打開,會看到輸出的結果,不允許跨域請求。 在javascript控制台程序中同樣可以看到錯誤提示:
那麼如果在返回響應頭header中注入Access-Control-Allow-Origin,這樣瀏覽器檢測到header中的Access-Control-Allow-Origin,則就可以跨域操作了。
同樣,如果使用ServcieStack,在很多地方可以支持CORS的跨域方式。最簡單的還是在AppHost的Configure函數裡面直接寫入:
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
this.AddPlugin(new CorsFeature());
}
這樣就可以了,相當於使用默認的CORS配置:
CorsFeature(allowedOrigins:"*",
allowedMethods:"GET, POST, PUT, DELETE, OPTIONS",
allowedHeaders:"Content-Type",
allowCredentials:false);
如果僅僅允許GET和POST的請求支持CORS,則只需要改為:
Plugins.Add(new CorsFeature(allowedMethods: "GET, POST"));
當然也可以在AppHost的Config裡面設置全局的CORS,如下:
/// <summary>
/// Application specific configuration
/// This method should initialize any IoC resources utilized by your web service classes.
/// </summary>
/// <param name="container"></param>
public override void Configure(Container container)
{
base.SetConfig(new EndpointHostConfig
{
GlobalResponseHeaders = {
{ "Access-Control-Allow-Origin", "*" },
{ "Access-Control-Allow-Methods", "GET, POST, PUT, DELETE, OPTIONS" },
{ "Access-Control-Allow-Headers", "Content-Type" },
},
});
}
現在運行WebService,使用postman或者Chrome調用這個請求,可以看到返回的值頭文件中,已經加上了響應頭,並且可以正常顯示返回結果了:
CORS使用起來簡單,不需要客戶端的額外處理,而且支持Post的方式提交請求,但是CORS的唯一一個缺點是對客戶端的瀏覽器版本有要求,支持CORS的瀏覽器機器版本如下:
總結
本文介紹了JavaScript中的跨域基本概念和產生的原因,以及如何解決跨域的兩種方法,一種是JSONP 一種是 CORS,在客戶端Javascript調用服務端介面的時候,如果需要支持跨域的話,需要服務端支持。JSONP的方式就是服務端對返回的值進行回調函數包裝,他的優點是支持眾多的瀏覽器, 缺點是僅支持Get的方式對服務端請求。另一種主流的跨域方案是CORS,他僅需要服務端在返回數據的時候在相應頭中加入標識信息。這種方式非常簡便。唯一的缺點是需要瀏覽器的支持,一些較老的瀏覽器可能不支持CORS特性。
跨域支持是創建WebService時應該考慮的一個功能點,希望本文對您在這邊面有所幫助,文中是使用ServiceStack來演示跨域支持的,如果您用的WCF的話,知道跨域原理的前提下,實現跨域應該不難。
參考資料:
https://github.com/ServiceStack/ServiceStack/wiki/Customize-HTTP-Responses
https://github.com/ServiceStack/ServiceStack/wiki/Request-and-response-filters
http://stackoverflow.com/questions/8211930/servicestack-rest-api-and-cors
http://stackoverflow.com/questions/15224038/rename-callback-parameter-for-jsonp
⑸ 跨域是指什麼,因為什麼引起的有哪些解決方案web前端知識
廣義跨域就是指跨域訪問,簡單來說就是 A 網站的 javascript 代碼試圖訪問 B 網站,包括提交內容和獲取內容。由於安全原因,跨域訪問是被各大瀏覽器所默認禁止的。
當一個域與其他域建立了信任關系後,2個域之間不但可以按需要相互進行管理,還可以跨網分配文件和列印機等設備資源,使不同的域之間實現網路資源的共享與管理。這就形成了「跨域」。
⑹ 如何防止web攻擊
SQL注入攻擊(SQL Injection)
攻擊者把SQL命令插入到Web表單的輸入域或頁面請求的字元串,欺騙伺服器執行惡意的SQL命令。在某些表單中,用戶輸入的內容直接用來構造(或者影響)動態SQL命令,或作為存儲過程的輸入參數,這類表單特別容易受到SQL注入式攻擊。
常見的SQL注入式攻擊過程類如:
1.某個Web應用有一個登錄頁面,這個登錄頁面控制著用戶是否有權訪問應用,它要求用戶輸入一個名稱和密碼;
2.登錄頁面中輸入的內容將直接用來構造動態的SQL命令,或者直接用作存儲過程的參數;
例如:
$query = 'SELECT * from Users WHERE login = ' . $username . ' AND password = ' . $password;
3.攻擊者在用戶名字和密碼輸入框中輸入'或'1'='1之類的內容;
4.用戶輸入的內容提交給伺服器之後,伺服器運行上面的代碼構造出查詢用戶的SQL命令,但由於攻擊者輸入的內容非常特殊,所以最後得到的SQL命令變成:
SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1';
5.伺服器執行查詢或存儲過程,將用戶輸入的身份信息和伺服器中保存的身份信息進行對比;
6.由於SQL命令實際上已被注入式攻擊修改,已經不能真正驗證用戶身份,所以系統會錯誤地授權給攻擊者。
如果攻擊者知道應用會將表單中輸入的內容直接用於驗證身份的查詢,他就會嘗試輸入某些特殊的SQL字元串篡改查詢改變其原來的功能,欺騙系統授予訪問許可權。
系統環境不同,攻擊者可能造成的損害也不同,這主要由應用訪問資料庫的安全許可權決定。如果用戶的帳戶具有管理員或其他比較高級的許可權,攻擊者就可能對資料庫的表執行各種他想要做的操作,包括添加、刪除或更新數據,甚至可能直接刪除表
防範方法:
1.檢查變數數據類型和格式
2.過濾特殊符號
3.綁定變數,使用預編譯語句
跨網站腳本攻擊(Cross Site scripting, XSS)
攻擊者將惡意代碼注入到網頁上,其他用戶在載入網頁時就會執行代碼,攻擊者可能得到包括但不限於更高的許可權(如執行一些操作)、私密網頁內容、會話和cookie等各種內容。這些惡意代碼通常是javascript、HTML以及其他客戶端腳本語言。
例如:
<?php
echo "歡迎您,".$_GET['name'];
常用的攻擊手段有:
盜用cookie,獲取敏感信息;
利用iframe、frame、xmlHttpRequest或上述Flash等方式,以(被攻擊)用戶的身份執行一些管理動作,或執行一些一般的如發微博、加好友、發私信等操作;
利用可被攻擊的域受到其他域信任的特點,以受信任來源的身份請求一些平時不允許的操作,如進行不當的投票活動;
在訪問量極大的一些頁面上的XSS可以攻擊一些小型網站,實現DDoS攻擊的效果。
防範方法:使用htmlspecialchars函數將特殊字元轉換成HTML編碼,過濾輸出的變數
跨網站請求偽造攻擊(Cross Site Request Forgeries, CSRF)
攻擊者偽造目標用戶的HTTP請求,然後此請求發送到有CSRF漏洞的網站,網站執行此請求後,引發跨站請求偽造攻擊。攻擊者利用隱蔽的HTTP連接,讓目標用戶在不注意的情況下單擊這個鏈接,由於是用戶自己點擊的,而他又是合法用戶擁有合法許可權,所以目標用戶能夠在網站內執行特定的HTTP鏈接,從而達到攻擊者的目的。
它與XSS的攻擊方法不同,XSS利用漏洞影響站點內的用戶,攻擊目標是同一站點內的用戶者,而CSRF 通過偽裝成受害用戶發送惡意請求來影響Web系統中受害用戶的利益。
例如:
某個購物網站購買商品時,採用shop.com/buy.php?item=watch&num=100
item參數確定要購買什麼物品,num參數確定要購買數量,如果攻擊者以隱藏的方式發送給目標用戶鏈接那麼如果目標用戶不小心訪問以後,購買的數量就成了100個
防範方法:
1、檢查網頁的來源
2、檢查內置的隱藏變數
3、使用POST,不要使用GET,處理變數也不要直接使用$_REQUEST
Session固定攻擊(Session Fixation)
這種攻擊方式的核心要點就是讓合法用戶使用攻擊者預先設定的session id來訪問被攻擊的應用程序,一旦用戶的會話ID被成功固定,攻擊者就可以通過此session id來冒充用戶訪問應用程序。
例如:
1.攻擊者訪問網站bank.com,獲取他自己的session id,如:SID=123;
2.攻擊者給目標用戶發送鏈接,並帶上自己的session id,如:bank.com/?SID=123;
3.目標用戶點擊了bank.com/?SID=123,像往常一樣,輸入自己的用戶名、密碼登錄到網站;
4.由於伺服器的session id不改變,現在攻擊者點擊bank.com/?SID=123,他就擁有了目標用戶的身份,可以為所欲為了。
防範方法:
1.定期更改session id
session_regenerate_id(TRUE);//刪除舊的session文件,每次都會產生一個新的session id。默認false,保留舊的session
2.更改session的名稱
session的默認名稱是PHPSESSID,此變數會保存在cookie中,如果攻擊者不抓包分析,就不能猜到這個名稱,阻擋部分攻擊[code]session_name("mysessionid");
復制代碼
3.關閉透明化session id
透明化session id指當瀏覽器中的http請求沒有使用cookie來制定session id時,sessioin id使用鏈接來傳遞
int_set("session.use_trans_sid", 0);
復制代碼
4.只從cookie檢查session id
int_set("session.use_cookies", 1);//表示使用cookies存放session id
int_set("session.use_only_cookies", 1);//表示只使用cookies存放session id
復制代碼
5.使用URL傳遞隱藏參數
$sid = md5(uniqid(rand()), TRUE));
$_SESSION["sid"] = $sid;//攻擊者雖然能獲取session數據,但是無法得知$sid的值,只要檢查sid的值,就可以確認當前頁面是否是web程序自己調用的
Session劫持攻擊(Session Hijacking)
會話劫持是指攻擊者利用各種手段來獲取目標用戶的session id。一旦獲取到session id,那麼攻擊者可以利用目標用戶的身份來登錄網站,獲取目標用戶的操作許可權。
攻擊者獲取目標用戶session id的方法:
1.暴力破解:嘗試各種session id,直到破解為止;
2.計算:如果session id使用非隨機的方式產生,那麼就有可能計算出來;
3.竊取:使用網路截獲,xss攻擊等方法獲得
防範方法:
1.定期更改session id
2.更改session的名稱
3.關閉透明化session id
4.設置HttpOnly。通過設置Cookie的HttpOnly為true,可以防止客戶端腳本訪問這個Cookie,從而有效的防止XSS攻擊。
文件上傳漏洞攻擊(File Upload Attack)
文件上傳漏洞指攻擊者利用程序缺陷繞過系統對文件的驗證與處理策略將惡意代碼上傳到伺服器並獲得執行伺服器端命令的能力。
常用的攻擊手段有:
上傳Web腳本代碼,Web容器解釋執行上傳的惡意腳本;
上傳Flash跨域策略文件crossdomain.xml,修改訪問許可權(其他策略文件利用方式類似);
上傳病毒、木馬文件,誘騙用戶和管理員下載執行;
上傳包含腳本的圖片,某些瀏覽器的低級版本會執行該腳本,用於釣魚和欺詐。
總的來說,利用的上傳文件要麼具備可執行能力(惡意代碼),要麼具備影響伺服器行為的能力(配置文件)。
防範方法:
1.文件上傳的目錄設置為不可執行;
2.判斷文件類型,設置白名單。對於圖片的處理,可以使用壓縮函數或者resize函數,在處理圖片的同時破壞圖片中可能包含的HTML代碼;
3.使用隨機數改寫文件名和文件路徑:一個是上傳後無法訪問;再來就是像shell.php.rar.rar和crossdomain.xml這種文件,都將因為重命名而無法攻擊;
4.單獨設置文件伺服器的域名:由於瀏覽器同源策略的關系,一系列客戶端攻擊將失效,比如上傳crossdomain.xml、上傳包含javascript的XSS利用等問題將得到解決。
⑺ 什麼是跨域,有什麼攻擊,如何防止攻擊
跨域是指跨區域,後面敏感字 有規定不能使用,請參考視頻
⑻ web跨域問題(java) 跨域請求
Socket處理HTTP請求太搞了吧?
用Restful Service做吧,如果需要安全認證,可以用HTTP基本認證方式。
⑼ nginx 怎麼解決webservice跨域
下載Nginx
網路搜索Nginx,找到官網下載,如果是Linux系統,直接輸入下面命令即可下載
wget http://nginx.org/download/nginx-1.8.1.tar.gz
我們這里使用的是1.8.1版本
安裝Nginx
使用tar xvf nginx-1.8.1.tar.gz命令,解壓剛下載文件,得到一個nginx-1.8.1目錄。
進入nginx-1.8.1,執行./configure --prefix=/usr/local/nginx命令,表示將nginx安裝到/usr/local/nginx目錄下。
在使用make & make install命令正式安裝nginx,完成後就可以在/usr/local/nginx目錄下看到已經裝好的nginx了。
如果安裝許可權不夠,請使用sudo make install命令。
模擬跨域錯誤
啟動Nginx,並在Nginx的html目錄下,編寫一個ajax.html頁面,在裡面通過ajax方式請求taobao的ip地址查詢api。
在瀏覽器中訪問http://127.0.0.1/ajax.html,然後按F12即可在Console裡面看到跨域錯誤。
下面我們就通過Nginx來解決這種跨域問題。
⑽ 前端web開發html如何避免js的跨域訪問
前端web開發html避免js的跨域訪問的方法是後台服務端做域配置兼容處理。
1、在server端請求過濾的時候加入以下控制:
<httpProtocol>
<customHeaders>
<add name="Access-Control-Allow-Origin" value="*" />
</customHeaders>
</httpProtocol>
Access-Control-Allow-Origin這個屬性配置成*就表示接受任何域過來的請求
2.ajax中請求如下:
$.ajax({
xhrFields: {
withCredentials: true
},
data:{ my: 'a' },
url: 'http://MyApp/Page', 這里是跨域訪問
type: 'POST'
})