eid
,並顯示給使用者。
String queryString = Window.Location.getQueryString();
int pos = queryString.indexOf("eid=")+4;
HTML output = new HTML();
output.setHTML(queryString.substring(pos, queryString.length()));
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。eid
並顯示給使用者。範例 2:請考慮使用 HTML 表單:
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<div id="myDiv">
Employee ID: <input type="text" id="eid"><br>
...
<button>Show results</button>
</div>
<div id="resultsDiv">
...
</div>
$(document).ready(function(){
$("#myDiv").on("click", "button", function(){
var eid = $("#eid").val();
$("resultsDiv").append(eid);
...
});
});
eid
) 只包含標準英數字元,這些程式碼便會正確地運作。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。
let element = JSON.parse(getUntrustedInput());
ReactDOM.render(<App>
{element}
</App>);
Example 3
中,如果攻擊者可以控制從 getUntrustedInput()
擷取的整個 JSON 物件,則可能會讓 React 將 element
解譯為元件,因此可以傳遞具有 dangerouslySetInnerHTML
及其自己的控制值的物件 (典型的 Cross-Site Scripting 攻擊)。
<script runat="server">
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;
</script>
EmployeeName
是定義如下的表單控制項:範例 2:以下 ASP.NET 程式碼片段的功能與之前的
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 1
相當,不過卻是以程式設計方式來實作所有的表單元素。
protected System.Web.UI.WebControls.Label EmployeeName;
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;
Name
值正常運作時,這些程式碼範例也會正常運作,但如果該值不正常運作時,則會完全無法避免程式碼遭受攻擊。這個程式碼之所以較不危險,是因為 Name
值是從雲端提供的儲存服務中讀取的,且顯然是由分散式應用程式管理這些值的內容。但是,如果 Name
的值是從使用者提供的資料中產生,那麼雲端提供的儲存服務可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這種類型的攻擊,被稱作 Inter-Component Communication Cloud XSS,是特別狡詐的,因為間接的資料儲存方式使得該威脅難以辨別,而且提高了該攻擊會影響到多個使用者的可能性。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login
和 EmployeeID
是定義如下的表單控制項:範例 4:以下的 ASP.NET 程式碼片段會示範以程式設計方式來實作
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 3
。
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
Example 1
和 Example 2
所述,如果 Login
只包含標準英數字元,這些範例就會正確運作。如果 Login
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。Example 1
和 Example 2
所述,應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Inter-Component Communication Cloud XSS 攻擊會在以下情況出現:攻擊者把危險內容注入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。Example 3
和 Example 4
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。eid
,並顯示給使用者。
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + eid)
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + row["emp"]')
...
Example 1
所述,name
的值正常運作時,此程式碼也會正常運作,但如果該值不正常運作,則會完全無法避免程式碼遭受攻擊。此外,這個程式碼之所以看似不那麼危險,是因為 name
的值是從資料庫中讀取的,而顯然這些內容是由應用程式管理的。但是,如果 name
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。Example 2
所述,應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。
from Crypto.PublicKey import RSA
key = RSA.generate(2048)
f = open('mykey.pem','w')
f.write(key.exportKey(format='PEM'))
f.close()
require 'openssl'
key = OpenSSL::PKey::RSA.new 2048
File.open('mykey.pem', 'w') do |file|
file.write(key.to_pem)
end
MQOD-ALTERNATEUSERID
和 MQOD-ALTERNATESECURITYID
欄位。
...
10 MQOD.
** Alternate user identifier
15 MQOD-ALTERNATEUSERID PIC X(12).
** Alternate security identifier
15 MQOD-ALTERNATESECURITYID PIC X(40).
...
...
ACCEPT MQOD-ALTERNATEUSERID.
ACCEPT MQOD-ALTERNATESECURITYID.
CALL 'MQOPEN' USING HCONN, MQOD, OPTS, HOBJ, COMPOCODE REASON.
...
=cmd|'/C calc.exe'!Z0
。如果開啟試算表 (在此範例中為開啟 Windows 小算盤) 的使用者信任文件來源,則會接受由試算表處理器顯示的所有安全性提示並讓裝載執行於其系統之上。
public void Service()
{
string name = HttpContext.Request["name"];
string data = GenerateCSVFor(name);
HttpContext.Response.Clear();
HttpContext.Response.Buffer = true;
HttpContext.Response.AddHeader("content-disposition", "attachment;filename=file.csv");
HttpContext.Response.Charset = "";
HttpContext.Response.ContentType = "application/csv";
HttpContext.Response.Output.Write(tainted);
HttpContext.Response.Flush();
HttpContext.Response.End();
}
=cmd|'/C calc.exe'!Z0
。如果開啟試算表 (在此範例中為開啟 Windows 小算盤) 的使用者信任文件來源,則會接受由試算表處理器顯示的所有安全性提示並讓裝載執行於其系統之上。
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
foo := r.FormValue("foo")
...
w := csv.NewWriter(file)
w.Write(foo)
}
=cmd|'/C calc.exe'!Z0
。如果開啟試算表 (在此範例中為開啟 Windows 小算盤) 的使用者信任文件來源,則會接受由試算表處理器顯示的所有安全性提示並讓裝載執行於其系統之上。
@RequestMapping(value = "/api/service.csv")
public ResponseEntity<String> service(@RequestParam("name") String name) {
HttpHeaders responseHeaders = new HttpHeaders();
responseHeaders.add("Content-Type", "application/csv; charset=utf-8");
responseHeaders.add("Content-Disposition", "attachment;filename=file.csv");
String data = generateCSVFor(name);
return new ResponseEntity<>(data, responseHeaders, HttpStatus.OK);
}
=cmd|'/C calc.exe'!Z0
。如果開啟試算表 (在此範例中為開啟 Windows 小算盤) 的使用者信任文件來源,則會接受由試算表處理器顯示的所有安全性提示並讓裝載執行於其系統之上。
@RequestMapping(value = "/api/service.csv")
fun service(@RequestParam("name") name: String): ResponseEntity<String> {
val responseHeaders = HttpHeaders()
responseHeaders.add("Content-Type", "application/csv; charset=utf-8")
responseHeaders.add("Content-Disposition", "attachment;filename=file.csv")
val data: String = generateCSVFor(name)
return ResponseEntity(data, responseHeaders, HttpStatus.OK)
}
PendingIntent
的旗標值設為 FLAG_MUTABLE
。建立的 Pending Intent 具有 FLAG_MUTABLE
旗標值時,很容易受到下游設定的未指定 Intent
欄位的影響,這可能會修改 Intent
的能力並使系統容易受到攻擊。PendingIntent
後修改其底層 Intent
,可能會使系統容易受到攻擊。這主要取決於底層 Intent
的整體能力。在大多數情況下,最佳方式是將 PendingIntent
旗標設為 FLAG_IMMUTABLE
來防止潛在問題。FLAG_MUTABLE
旗標值建立 PendingIntent
。
...
val intent_flag_mut = Intent(Intent.ACTION_GTALK_SERVICE_DISCONNECTED, Uri.EMPTY, this, DownloadService::class.java)
val flag_mut = PendingIntent.FLAG_MUTABLE
val pi_flagmutable = PendingIntent.getService(
this,
0,
intent_flag_mut,
flag_mut
)
...
setuid root
的程式。程式代表無權限使用者執行了特定的檔案操作,並使用存取檢查來確保它不使用其根權限執行目前使用者不應該執行的操作。程式使用 access()
系統呼叫來檢查在程式開啟檔案和執行必要操作之前,執行程式的使用者是否具有權限去存取這些指定的檔案。
if (!access(file,W_OK)) {
f = fopen(file,"w+");
operate(f);
...
}
else {
fprintf(stderr,"Unable to open file %s.\n",file);
}
access()
呼叫的運作方式在意料之中,而且,如果執行程式的使用者具有必要的權限來編輯檔案,那麼就會回傳 0
,其他情況則會回傳-1。無論怎樣,因為 access()
和 fopen()
都是對檔案名稱進行操作,而不是對檔案控制碼進行操作,所以當 file
變數傳送到 fopen()
的時候,就不能保證這個變數仍然能夠像傳送到 access()
的時候那樣參照磁碟上相同的檔案。如果攻擊者在 access()
呼叫之後,用指向不同檔案的一個象徵連結來取代 file
,程式就會使用它的根權限對檔進行操作,即使這個檔案攻擊者在其他情況下是無法篡改的。藉由欺騙程式去執行其他情況下不被允許的操作,攻擊者就能取得權限的提高。root
權限,因而沒有受到程式的限制。如果應用程式有能力執行攻擊者在其他情況下不被允許的任何操作,那麼這個程式就是一個可能的攻擊目標。
fd = creat(FILE, 0644); /* Create file */
if (fd == -1)
return;
if (chown(FILE, UID, -1) < 0) { /* Change file owner */
...
}
chown()
呼叫所操作的檔案與對 creat()
的呼叫所建立的檔案相同,但實際上未必如此。由於 chown()
是針對檔案名稱 (而非檔案控制碼) 進行操作,因此攻擊者可能會使用並非由攻擊者所擁有的檔案連結來取代檔案。隨後,對 chown()
的呼叫會為攻擊者提供所連結檔案的擁有權。CBL_CHECK_FILE_EXIST
常式,以在建立檔案之前先檢查檔案是否存在,並執行必要的操作。
CALL "CBL_CHECK_FILE_EXIST" USING
filename
file-details
RETURNING status-code
END-CALL
IF status-code NOT = 0
MOVE 3 to access-mode
MOVE 0 to deny-mode
MOVE 0 to device
CALL "CBL_CREATE_FILE" USING
filename
access-mode
deny-mode
device
file-handle
RETURNING status-code
END-CALL
END-IF
CBL_CHECK_FILE_EXIST
呼叫的運作方式在意料之中,並傳回一個非零值,表示該檔案不存在。不過,因為 CBL_CHECK_FILE_EXIST
和 CBL_CREATE_FILE
都是對檔案名稱進行操作,而不是對檔案控制碼進行操作,所以當 filename
變數傳遞到 CBL_CREATE_FILE
的時候,就不能保證這個變數仍然能夠像傳遞到 CBL_CHECK_FILE_EXIST
的時候那樣參照磁碟上相同的檔案。如果攻擊者在 CBL_CHECK_FILE_EXIST
呼叫後建立 filename
,CBL_CREATE_FILE
的呼叫將會失敗,進而導致程式認為該檔案是空的,但實際上它包含由攻擊者控制的資料。root
權限的程式,以代表無權限使用者執行特定檔案操作,並使用存取測試來確保它沒有使用其根權限來執行操作,這種權限對目前使用者來說在其他情況下是無法取得的。藉由欺騙程式去執行其他情況下不被允許的操作,攻擊者就可能取得提升的權限。eid
,並向使用者顯示。
String eid = Request["eid"];
...
EmployeeID.Text = eid;
EmployeeID
是定義如下的伺服器端 ASP.NET 控制項:
<form runat="server">
...
<asp:Label id="EmployeeID" runat="server"/>
...
</form>
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。
...
string name = "";
using (SqlConnection conn = new SqlConnection(_ConnectionString))
{
string eid = Request["eid"];
SqlCommand cmd = new SqlCommand("SELECT * FROM emp WHERE id = @id", conn);
cmd.Parameters.AddWithValue("@id", eid);
conn.Open();
SqlDataReader objReader = cmd.ExecuteReader();
while (objReader.Read())
{
name = objReader["name"];
}
objReader.Close();
}
...
EmployeeName.Text = name;
EmployeeName
是定義如下的伺服器端 ASP.NET 控制項:
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server"/>
...
</form>
Example 2
所述,name
的值正常運作時,此程式碼也會正常運作,但如果該值不正常運作,則會完全無法避免程式碼遭受攻擊。此外,這個程式碼之所以看似不那麼危險,是因為 name
的值是從資料庫中讀取的,而顯然這些內容是由應用程式管理的。但是,如果 name
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。Example 2
所述,應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。user
,並向使用者顯示。
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", user)
}
user
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 user
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。
func someHandler(w http.ResponseWriter, r *http.Request){
...
row := db.QueryRow("SELECT name FROM users WHERE id =" + userid)
err := row.Scan(&name)
...
fmt.Fprintln(w, "Username is: ", name)
}
Example 1
所述,name
的值正常運作時,此程式碼也會正常運作,但如果該值不正常運作,則會完全無法避免程式碼遭受攻擊。此外,這個程式碼之所以看似不那麼危險,是因為 name
的值是從資料庫中讀取的,而顯然這些內容是由應用程式管理的。但是,如果 name
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果沒有對所有儲存在資料庫中的資料進行適當的輸入驗證,那麼攻擊者即可在使用者的網頁瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其極其隱蔽,會因為間接的資料儲存方式而難以辨別該威脅,並會提高影響多個使用者的可能性。XSS 弱點會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1
所示,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由網頁瀏覽器執行時,就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。Example 2
所示,應用程式會將危險資料儲存在資料庫或其他可信任的資料存放區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者執行需要權限許可的操作,或者取得存取使用者專屬敏感資料的權限。
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
url
的值以 javascript:
開頭,隨後的 JavaScript 程式碼將在網頁範圍中的 WebView 內執行。eid
,並將其向使用者顯示。
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <%= name %>
Example 2
所述,name
的值正常運作時,此程式碼也會正常運作,但如果該值不正常運作,則會完全無法避免程式碼遭受攻擊。此外,這個程式碼之所以看似不那麼危險,是因為 name
的值是從資料庫中讀取的,而顯然這些內容是由應用程式管理的。但是,如果 name
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1
所述,應用程式以外的來源會在資料庫或是其他資料儲存區中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。Example 2
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。Example 3
所述,應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
url
的值以 javascript:
開頭,隨後的 JavaScript 程式碼將在網頁範圍中的 WebView 內執行。eid
,然後在 servlet 的回應中向使用者顯示其值。
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
eid
只包含標準英數字元,則這個範例中的程式碼會正確地執行。如果 eid
中有包含中繼字元或來源程式碼中的值,那麼網路瀏覽器就會像顯示 HTTP 回應那樣執行程式碼。
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
Example 2
所述,name
的值正常運作時,此程式碼也會正常運作,但如果該值不正常運作,則會完全無法避免程式碼遭受攻擊。此外,這個程式碼之所以看似不那麼危險,是因為 name
的值是從資料庫中讀取的,而顯然這些內容是由應用程式管理的。但是,如果 name
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1
所述,應用程式以外的來源會在資料庫或是其他資料儲存區中儲存危險資料,且之後這些危險資料會被當作信賴的資料回讀到應用程式,並會包含在動態內容中。Example 2
所述,會直接從 HTTP 要求中讀取資料,並在 HTTP 回應中回傳資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。Example 3
所述,應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。
...
@property (strong, nonatomic) NSString *webContentFromURL;
...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
...
[self setWebContentFromURL:[url host]];
...
...
...
@property (strong, nonatomic) WKWebView *webView;
...
AppDelegate *appDelegate = (AppDelegate *)[[UIApplication sharedApplication] delegate];
...
[_webView loadHTMLString:appDelegate.webContentFromURL] baseURL:nil];
...
...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView loadHTMLString:_inputTextField.text baseURL:nil];
...
inputTextField
中的文字只包含標準英數字元,這個範例中的程式碼便會正常運作而不會有問題。如果 inputTextField
中的文字包括中繼字元或原始程式碼,那麼網路瀏覽器就會像顯示 HTTP 回應那樣,可能會將輸入當成程式碼來執行。
...
@property (strong, nonatomic) WKWebView *webView;
...
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Employee" inManagedObjectContext:context];
[fetchRequest setEntity:entity];
NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error];
for (NSManagedObject *info in fetchedObjects) {
NSString msg = @"Hello, " + [info valueForKey:@"name"];
[_webView loadHTMLString:msg baseURL:nil]
...
}
...
Example 2
所述,name
的值正常運作時,此程式碼也會正常運作,但如果該值不正常運作,則會完全無法避免程式碼遭受攻擊。此外,這個程式碼之所以看似不那麼危險,是因為 name
的值是從資料庫中讀取的,而顯然這些內容是由應用程式管理的。但是,如果 name
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1
所述,目標應用程式以外的來源會使用目標應用程式的自訂 URL 架構提出 URL 要求,之後來自此 URL 要求的未驗證資料會被當作信賴的資料讀回到應用程式,並會包含在動態內容中。Example 2
所述,會直接從使用者可控制的 UI 元件讀取資料,並在 HTTP 回應中傳回資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。Example 3
所述,應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = WKWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
loadHTMLString:
的字串是使用者可控制的,並且 WKWebView 內依預設已啟用 JavaScript,因此使用者可透過使用應用程式自訂 URL 架構的要求,將任意內容 (包括可執行檔指令碼) 寫入 WKWebView。
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField
中的文字只包含標準英數字元,這個範例中的程式碼便會正常運作而不會有問題。如果 inputTextField
中的文字包括中繼字元或原始程式碼,那麼網路瀏覽器就會像顯示 HTTP 回應那樣,可能會將輸入當成程式碼來執行。
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Employee", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
do {
let results = try managedContext.executeFetchRequest(fetchRequest)
let result : NSManagedObject = results.first!
let name : String = result.valueForKey("name")
let msg : String = "Hello, \(name)"
let webView : UIWebView = UIWebView()
webView.loadHTMLString(msg, baseURL:nil)
} catch let error as NSError {
print("Error \(error)")
}
Example 2
所述,name
的值正常運作時,此程式碼也會正常運作,但如果該值不正常運作,則會完全無法避免程式碼遭受攻擊。此外,這個程式碼之所以看似不那麼危險,是因為 name
的值是從資料庫中讀取的,而顯然這些內容是由應用程式管理的。但是,如果 name
的值是從使用者提供的資料中產生,那麼資料庫可能會成為提供惡意內容的管道。如果未對資料庫中儲存的所有資料進行適當的輸入驗證,那麼攻擊者可能在使用者的網路瀏覽器中執行惡意指令。這類型的攻擊稱為 Persistent XSS (或 Stored XSS),其性質特別狡詐,因為間接的資料儲存方式而難以辨別該威脅,且該攻擊影響多個使用者的可能性可能提高。XSS 盜取會從存取提供造訪者訪客留名簿 (guestbook) 的網站開始。攻擊者會在他們的訪客留名簿項目中加入 JavaScript,所有後來前往訪客留名簿頁面的造訪者都可能會執行這些惡意程式碼。Example 1
所述,目標應用程式以外的來源會使用目標應用程式的自訂 URL 架構提出 URL 要求,之後來自此 URL 要求的未驗證資料會被當作信賴的資料讀回到應用程式,並會包含在動態內容中。Example 2
所述,會直接從使用者可控制的 UI 元件讀取資料,並在 HTTP 回應中傳回資料。當攻擊者誘使使用者提供危險內容給易受攻擊的 Web 應用程式,接著這些危險內容就會回傳給使用者並由在網路瀏覽器中執行,這時就會出現 Reflected XSS 攻擊行為。傳遞惡意內容最常用的機制就是,將惡意內容當作參數隱藏在公開發表的 URL 中,或者以電子郵件方式直接傳送給受害者。以這種方法建立的 URL 會構成許多網路釣魚 (phishing) 架構的核心,攻擊者可以藉此誘使受害者去造訪一個指向到易受攻擊網站的 URL。網站將攻擊者的內容回傳給使用者之後,就會執行這些內容,並接著從使用者的電腦將可能包含階段作業資訊的 Cookie 之類的私人資訊傳給攻擊者,或者執行其他惡意活動。Example 3
所述,應用程式會將危險資料儲存到資料庫或其他可信任的資料儲存區中。這些危險資料隨後會被回讀到應用程式,並包含在動態內容中。Persistent XSS 攻擊會在以下情況出現:攻擊者把危險內容插入到之後會讀取的資料儲存區中,並包含在動態內容中。從攻擊者的角度來看,插入惡意內容的最佳位置莫過於一個會對很多使用者或特別感興趣的使用者顯示的區域。感興趣的使用者通常會在應用程式中擁有較高的權限,或者會與敏感資料進行互動,且這些資料對攻擊者而言很有利用價值。如果其中一個使用者執行了惡意內容,攻擊者可能會代替使用者去執行需要權限許可的作業,或者取得存取使用者專屬敏感資料的權限。xp_cmdshell
函數。不應使用該函數。xp_cmdshell
函數會啟動 Windows 指令 shell,以執行提供的指令字串。該指令會在預設系統或提供的代理伺服器環境中執行。但是,沒有方法可以將使用者限制為預先指定的權限操作組合,任何權限授予都會開放使用者執行任何指令字串。chroot()
系統呼叫的不適當使用會讓攻擊者避開系統的封鎖。chroot()
系統呼叫允許程式修改其 File System 的根目錄含義。在適當地進行 chroot()
呼叫之後,程式無法存取新根目錄所定義的目錄樹狀架構之外的任何檔案。這樣的環境叫作 chroot jail,通常是用來阻止程式被推翻、並用來存取未經授權檔案的可能性。例如,很多 FTP 伺服器在 chroot jail 環境中執行,以便用來防止發現新伺服器弱點的攻擊者有能力下載密碼檔或者其他系統中的敏感檔案。chroot()
可能會讓攻擊者避開 chroot jail。因為 chroot()
函數呼叫不會改變程式目前的工作目錄,所以在呼叫 chroot()
之後,相關路徑仍然會參照 chroot jail 之外的 File System 資源。
chroot("/var/ftproot");
...
fgets(filename, sizeof(filename), network);
localfile = fopen(filename, "r");
while ((len = fread(buf, 1, sizeof(buf), localfile)) != EOF) {
fwrite(buf, 1, sizeof(buf), network);
}
fclose(localfile);
GET
。FTP 伺服器在其初始化程式中呼叫 chroot()
,以避免存取 /var/ftproot
以外的檔案。但是,因為伺服器沒能藉由呼叫 chdir("/")
來變更目前的工作目錄,所以攻擊者就能要求檔案 "../../../../../etc/passwd
",並取得系統密碼檔案的副本。varName
提供惡意值,則呼叫 SetVariable()
時可能會覆寫包括 #first#
在內的任意變數。在此案例中,若包含 JavaScript 的惡意值覆寫 #first#
,此程式會容易受到 Cross-Site Scripting 攻擊。
<cfset first = "User">
<cfscript>
SetVariable(url.varName, url.varValue);
</cfscript>
<cfoutput>
#first#
</cfoutput>
str
提供惡意值,則呼叫 parse_str()
時可能會在目前範圍中覆寫包括 first
在內的任意變數。在此案例中,若包含 JavaScript 的惡意值覆寫 first
,此程式會容易受到 Cross-Site Scripting 攻擊。
<?php
$first="User";
...
$str = $_SERVER['QUERY_STRING'];
parse_str($str);
echo $first;
?>
str
提供惡意值,則呼叫 mb_parse_str()
時可能會覆寫包括 first
在內的任意變數。在此案例中,若包含 JavaScript 的惡意值覆寫 first
,此程式會容易受到 Cross-Site Scripting 攻擊。
<?php
$first="User";
...
$str = $_SERVER['QUERY_STRING'];
mb_parse_str($str);
echo $first;
?>
<http auto-config="true">
...
<session-management session-fixation-protection="none"/>
</http>
Example 1
中,攻擊者使用直接明顯的方法並不高明,對於攻擊知名度較低的網站並不適用。但是,千萬不要過於大意,攻擊者有許多手段來突破上述攻擊的限制。攻擊者最常採用的技術包括:利用目標網站中的 Cross-Site Scripting 或 HTTP Response Splitting 弱點 [1]。透過誘使受害者向一個易受攻擊的應用程式提交惡意要求,讓應用程式將 JavaScript 或者其他程式碼反映到受害者的瀏覽器,這樣一來,攻擊者就可以建立 Cookie,使受害者重新使用受攻擊者控制的階段作業識別碼。bank.example.com
和 recipes.example.com
),其中一個應用程式存在弱點,那麼攻擊者便可以透過此弱點設定一個 Cookie,並在其中包含已修改的階段作業識別碼,且該階段作業識別碼可以在 example.com
[2] 網域上的所有應用程式中交互使用。use_strict_mode
屬性。
ini_set("session.use_strict_mode", "0");
doExchange()
拋出的罕見異常。
try {
doExchange();
}
catch (RareException e) {
// this can never happen
}
RareException
,程式會繼續執行,就像什麼都沒有發生過一樣。程式不會記錄有關此特殊情況,這將使得事後嘗試尋找程式此異常的運作方式變得很困難。DoExchange()
拋出的罕見異常。
try {
DoExchange();
}
catch (RareException e) {
// this can never happen
}
RareException
,程式會繼續執行,就像什麼都沒有發生過一樣。程式不會記錄有關此特殊情況,這將使得事後嘗試尋找程式此異常的運作方式變得很困難。doExchange()
拋出的罕見異常。
try {
doExchange();
}
catch (RareException e) {
// this can never happen
}
RareException
,程式會繼續執行,就像什麼都沒有發生過一樣。程式不會記錄有關此特殊情況,這將使得事後嘗試尋找程式此異常的運作方式變得很困難。doExchange()
拋出的罕見異常。
try {
doExchange();
}
catch (exception $e) {
// this can never happen
}
RareException
,程式會繼續執行,就像什麼都沒有發生過一樣。程式不會記錄有關此特殊情況,這將使得事後嘗試尋找程式此異常的運作方式變得很困難。open()
拋出的罕見異常。
try:
f = open('myfile.txt')
s = f.readline()
i = int(s.strip())
except:
# This will never happen
pass
RareException
,程式會繼續執行,就像什麼都沒有發生過一樣。程式不會記錄有關此特殊情況,這將使得事後嘗試尋找程式此異常的運作方式變得很困難。
...
<configuration>
<system.web>
<authentication>
<forms
timeout="60" />
</authentication>
</system.web>
</configuration>
...
low
階段作業安全性配置的 CakePHP。
Configure::write('Security.level', 'low');
Session.timeout
設定配合使用,Security.level
設定可定義階段作業的有效時間。實際階段作業逾時時間等於 Session.timeout
乘以下列其中一項倍數:noopen
的 X-Download-Options
標頭,允許下載的 HTML 頁面在網站向其提供的安全環境中執行。
var express = require('express');
var app = express();
var helmet = require('helmet');
app.use(helmet({
ieNoOpen: false
}));
...
...
HttpSession sesssion = request.getSession(true);
sesssion.setMaxInactiveInterval(-1);
...
<session-config>
<session-timeout>-1</session-timeout>
</session-config>
<session-timeout>
標籤定義 Web 應用程式中,所有工作階段的預設逾時時間間隔。如果沒有 <session-timeout>
標籤,就會交由容器來設定預設逾時時間。