<apex:page controller="accessControl">
<apex:pageBlock >
<apex:pageBlockSection >
<apex:outputText value="Survey Name: "/>
<apex:inputText value="{!surveyName}"/>
</apex:pageBlockSection>
<apex:pageBlockSection >
<apex:outputText value="New Name: "/>
<apex:inputText value="{!newSurveyName}"/>
</apex:pageBlockSection>
<apex:pageBlockSection >
<apex:commandButton value="Update" action="{!updateName}"/>
</apex:pageBlockSection>
</apex:pageBlock>
</apex:page>
public String surveyName { get; set; }
public String newSurveyName { get; set; }
public PageReference updateName() {
Survey__c s = [SELECT Name FROM Survey__c WHERE Name=:surveyName];
s.Name = newSurveyName;
update s;
PageReference page = ApexPages.currentPage();
page.setRedirect(true);
return page;
}
DATA: id TYPE i.
...
id = request->get_form_field( 'invoiceID' ).
CONCATENATE `INVOICEID = '` id `'` INTO cl_where.
SELECT *
FROM invoices
INTO CORRESPONDING FIELDS OF TABLE itab_invoices
WHERE (cl_where).
ENDSELECT.
...
ID의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.
...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var id:int = int(Number(params["invoiceID"]));
var query:String = "SELECT * FROM invoices WHERE id = :id";
stmt.sqlConnection = conn;
stmt.text = query;
stmt.parameters[":id"] = id;
stmt.execute();
...
id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.inputID 값은 사전 정의된 목록에서 제공되며, 바인딩 변수는 SOQL/SOSL injection을 방지하는 데 도움이 됩니다.
...
result = [SELECT Name, Phone FROM Contact WHERE (IsDeleted = false AND Id=:inputID)];
...
inputID의 값을 수정하지 못하도록 방지하기에는 불충분하다는 점입니다. 공격자가 인터페이스를 우회하고 다른 값으로 요청을 전송할 수 있는 경우 공격자는 다른 연락처 정보에 액세스할 수 있습니다. 이 예제의 코드는 사용자가 요청된 연락처에 액세스할 수 있는 권한이 있는지 확인하지 않으므로, 사용자가 볼 권한이 없는 경우에도 모든 연락처를 표시합니다.
...
int16 id = System.Convert.ToInt16(invoiceID.Text);
var invoice = OrderSystem.getInvoices()
.Where(new Invoice { invoiceID = id });
...
id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.
...
CMyRecordset rs(&dbms);
rs.PrepareSQL("SELECT * FROM invoices WHERE id = ?");
rs.SetParam_int(0,atoi(r.Lookup("invoiceID").c_str()));
rs.SafeExecuteSQL();
...
id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.
...
ACCEPT ID.
EXEC SQL
DECLARE C1 CURSOR FOR
SELECT INVNO, INVDATE, INVTOTAL
FROM INVOICES
WHERE INVOICEID = :ID
END-EXEC.
...
ID의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.deleteDatabase 메서드를 실행하면 공격자가 모든 데이터베이스를 삭제할 수 있게 됩니다.
...
id := request.FormValue("invoiceID")
query := "SELECT * FROM invoices WHERE id = ?";
rows, err := db.Query(query, id)
...
id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.
...
id = Integer.decode(request.getParameter("invoiceID"));
String query = "SELECT * FROM invoices WHERE id = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setInt(1, id);
ResultSet results = stmt.execute();
...
id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.Example 1을 Android 플랫폼에 맞게 조정합니다.
...
String id = this.getIntent().getExtras().getString("invoiceID");
String query = "SELECT * FROM invoices WHERE id = ?";
SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
Cursor c = db.rawQuery(query, new Object[]{id});
...
...
var id = document.form.invoiceID.value;
var query = "SELECT * FROM invoices WHERE id = ?";
db.transaction(function (tx) {
tx.executeSql(query,[id]);
}
)
...
id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.
...
NSManagedObjectContext *context = [appDelegate managedObjectContext];
NSEntityDescription *entityDesc = [NSEntityDescription entityForName:@"Invoices" inManagedObjectContext:context];
NSFetchRequest *request = [[NSFetchRequest alloc] init];
[request setEntity:entityDesc];
NSPredicate *pred = [NSPredicate predicateWithFormat:@"(id = %@)", invoiceId.text];
[request setPredicate:pred];
NSManagedObject *matches = nil;
NSError *error;
NSArray *objects = [context executeFetchRequest:request error:&error];
if ([objects count] == 0) {
status.text = @"No records found.";
} else {
matches = [objects objectAtIndex:0];
invoiceReferenceNumber.text = [matches valueForKey:@"invRefNum"];
orderNumber.text = [matches valueForKey:@"orderNumber"];
status.text = [NSString stringWithFormat:@"%d records found", [objects count]];
}
[request release];
...
id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.
...
$id = $_POST['id'];
$query = "SELECT * FROM invoices WHERE id = ?";
$stmt = $mysqli->prepare($query);
$stmt->bind_param('ss',$id);
$stmt->execute();
...
id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.
procedure get_item (
itm_cv IN OUT ItmCurTyp,
id in varchar2)
is
open itm_cv for ' SELECT * FROM items WHERE ' ||
'invoiceID = :invid' ||
using id;
end get_item;
id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.
...
id = request.POST['id']
c = db.cursor()
stmt = c.execute("SELECT * FROM invoices WHERE id = %s", (id,))
...
id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.
...
id = req['invoiceID'].respond_to(:to_int)
query = "SELECT * FROM invoices WHERE id=?"
stmt = conn.prepare(query)
stmt.execute(id)
...
id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.
def searchInvoice(value:String) = Action.async { implicit request =>
val result: Future[Seq[Invoice]] = db.run {
sql"select * from invoices where id=$value".as[Invoice]
}
...
}
id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.
...
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Invoices", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
let pred : NSPredicate = NSPredicate(format:"(id = %@)", invoiceId.text)
fetchRequest.setPredicate = pred
do {
let results = try managedContext.executeFetchRequest(fetchRequest)
let result : NSManagedObject = results.first!
invoiceReferenceNumber.text = result.valueForKey("invRefNum")
orderNumber.text = result.valueForKey("orderNumber")
status.text = "\(results.count) records found"
} catch let error as NSError {
print("Error \(error)")
}
...
id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.
...
id = Request.Form("invoiceID")
strSQL = "SELECT * FROM invoices WHERE id = ?"
objADOCommand.CommandText = strSQL
objADOCommand.CommandType = adCmdText
set objADOParameter = objADOCommand.CreateParameter("id" , adString, adParamInput, 0, 0)
objADOCommand.Parameters("id") = id
...
id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.with sharing: 사용자 공유 규칙이 적용됩니다.without sharing: 공유 규칙이 적용되지 않습니다.inherited sharing: 호출 클래스의 공유 규칙이 적용됩니다. 호출 클래스가 공유 키워드를 지정하지 않거나 클래스 자체가 Visualforce 컨트롤러와 같은 진입점인 경우에는 사용자 공유 규칙이 기본적으로 적용됩니다.
public class MyClass1 {
public List<Contact> getAllTheSecrets() {
return Database.query('SELECT Name FROM Contact');
}
}
public without sharing class MyClass2 {
public List<Contact> getAllTheSecrets() {
return Database.query('SELECT Name FROM Contact');
}
}
public inherited sharing class MyClass3 {
public List<Contact> getAllTheSecrets() {
return Database.query('SELECT Name FROM Contact');
}
}
MyClass1 및 MyClass2가 안전하지 않은 이유는 사용자 공유 규칙을 적용하지 않고도 레코드를 검색할 수 있기 때문입니다.MyClass3의 경우에는 기본적으로 공유 규칙을 적용하므로 더 안전합니다. 그러나 without sharing을 명시적으로 선언하는 클래스에서 getAllTheSecrets() 함수를 호출하는 경우에는 여전히 무단 액세스 권한을 부여할 수 있습니다.true로 설정된 isSecure 매개 변수 없이 쿠키가 생성됩니다.Secure 플래그를 지원합니다. 플래그가 설정되면 브라우저는 HTTPS를 통해 쿠키를 전송하기만 합니다. 암호화되지 않은 채널을 통해 쿠키를 전송하면 네트워크 염탐 공격에 노출될 수 있으며 안전한 플래그를 사용하는 것이 쿠키의 값 자격 증명을 유지하는 데 도움을 줍니다. 이것은 쿠키가 개인 정보를 포함하거나 세션 ID를 전하는 경우 특히 중요합니다.isSecure 매개 변수를 true로 설정하지 않고 쿠키를 생성합니다.
...
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, false, 'Strict');
...
isSecure 매개 변수를 설정하지 않는 경우, HTTPS 요청 중에 전송된 쿠키는 다음 HTTP 요청 중에도 전송됩니다. 암호화되지 않은 무선 연결을 통한 네트워크 트래픽 염탐은 공격자에게는 간단한 작업이며 HTTP를 통한 쿠키(특히 세션 ID가 있는 쿠키) 전송은 응용 프로그램을 손상시킬 수 있습니다.true로 설정된 Secure 플래그 없이 쿠키가 생성됩니다.Secure 플래그를 지원합니다. 플래그가 설정되면 브라우저는 HTTPS를 통해 쿠키를 전송하기만 합니다. 암호화되지 않은 채널을 통해 쿠키를 전송하면 네트워크 염탐 공격에 노출될 수 있으므로 안전한 플래그를 사용하는 것이 쿠키의 값 자격 증명을 유지하는 데 도움을 줍니다. 이것은 쿠키가 개인 정보를 포함하거나 세션 ID를 전하는 경우 특히 중요합니다.Secure 속성 설정 없이 쿠키가 응답에 추가되었습니다.
...
HttpCookie cookie = new HttpCookie("emailCookie", email);
Response.AppendCookie(cookie);
...
Secure 플래그를 설정하지 않는 경우, HTTPS 요청 중에 전송된 쿠키는 다음 HTTP 요청 중에도 전송됩니다. 암호화되지 않은 무선 연결을 통한 네트워크 트래픽 염탐은 공격자에게는 간단한 작업이므로 HTTP를 통한 쿠키(특히 세션 ID가 있는 쿠키) 전송은 응용 프로그램을 손상시킬 수 있습니다.Secure 플래그를 true로 설정하지 않고 쿠키를 생성합니다.Secure 플래그를 지원합니다. 플래그가 설정되면 브라우저는 HTTPS를 통해 쿠키를 전송하기만 합니다. 암호화되지 않은 채널을 통해 쿠키를 전송하면 네트워크 염탐 공격에 노출될 수 있으므로 안전한 플래그를 사용하는 것이 쿠키의 값 자격 증명을 유지하는 데 도움을 줍니다. 이는 쿠키가 개인 데이터 또는 세션 ID를 포함하거나 CSRF 토큰을 전하는 경우 특히 중요합니다.Secure 플래그를 설정하지 않고 쿠키를 응답에 추가합니다.
cookie := http.Cookie{
Name: "emailCookie",
Value: email,
}
http.SetCookie(response, &cookie)
...
Secure 플래그를 설정하지 않는 경우, HTTPS 요청 중에 전송된 쿠키는 다음 HTTP 요청 중에도 전송됩니다. 그러면 공격자가 암호화되지 않은 네트워크 트래픽을 염탐(무선 네트워크를 통하는 경우 특히 쉬움)하여 쿠키를 손상시킬 수 있습니다.true로 설정된 Secure 플래그 없이 쿠키가 생성됩니다.Secure 플래그를 지원합니다. 플래그가 설정되면 브라우저는 HTTPS를 통해 쿠키를 전송하기만 합니다. 암호화되지 않은 채널을 통해 쿠키를 전송하면 네트워크 염탐 공격에 노출될 수 있으므로 안전한 플래그를 사용하는 것이 쿠키의 값 자격 증명을 유지하는 데 도움을 줍니다. 이것은 쿠키가 개인 정보를 포함하거나 세션 ID를 전하는 경우 특히 중요합니다.use-secure-cookie 속성은 remember-me 쿠키가 암호화되지 않은 전송을 통해 전송되도록 합니다.
<http auto-config="true">
...
<remember-me use-secure-cookie="false"/>
</http>
Secure 플래그를 설정하지 않는 경우, HTTPS 요청 중에 전송된 쿠키는 다음 HTTP 요청 중에도 전송됩니다. 암호화되지 않은 무선 연결을 통한 네트워크 트래픽 염탐은 공격자에게는 간단한 작업이므로 HTTP를 통한 쿠키(특히 세션 ID가 있는 쿠키) 전송은 응용 프로그램을 손상시킬 수 있습니다.true로 설정된 Secure 플래그 없이 쿠키가 생성됩니다.Secure 플래그를 지원합니다. 플래그가 설정되면 브라우저는 HTTPS를 통해 쿠키를 전송하기만 합니다. 암호화되지 않은 채널을 통해 쿠키를 전송하면 네트워크 염탐 공격에 노출될 수 있으므로 안전한 플래그를 사용하는 것이 쿠키의 값 자격 증명을 유지하는 데 도움을 줍니다. 이것은 쿠키가 개인 정보를 포함하거나 세션 ID를 전하는 경우 특히 중요합니다.Secure 속성에 대한 true 설정 없이 쿠키가 응답에 추가되었습니다.
res.cookie('important_cookie', info, {domain: 'secure.example.com', path: '/admin', httpOnly: true, secure: false});
Secure 플래그를 설정하지 않는 경우, HTTPS 요청 중에 전송된 쿠키는 다음 HTTP 요청 중에도 전송됩니다. 암호화되지 않은 무선 연결을 통한 네트워크 트래픽 염탐은 공격자에게는 간단한 작업이므로 HTTP를 통한 쿠키(특히 세션 ID가 있는 쿠키) 전송은 응용 프로그램을 손상시킬 수 있습니다.TRUE로 설정된 NSHTTPCookieSecure 플래그 없이 쿠키가 생성됩니다.Secure 플래그를 지원합니다. 플래그가 설정되면 브라우저는 HTTPS를 통해 쿠키를 전송하기만 합니다. 암호화되지 않은 채널을 통해 쿠키를 전송하면 네트워크 염탐 공격에 노출될 수 있으므로 안전한 플래그를 사용하는 것이 쿠키의 값 자격 증명을 유지하는 데 도움을 줍니다. 이것은 쿠키가 개인 정보를 포함하거나 세션 ID를 전하는 경우 특히 중요합니다.Secure 플래그 설정 없이 쿠키가 응답에 추가되었습니다.
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
Secure 플래그를 설정하지 않는 경우, HTTPS 요청 중에 전송된 쿠키는 다음 HTTP 요청 중에도 전송됩니다. 암호화되지 않은 무선 연결을 통한 네트워크 트래픽 염탐은 공격자에게는 간단한 작업이므로 HTTP를 통한 쿠키(특히 세션 ID가 있는 쿠키) 전송은 응용 프로그램을 손상시킬 수 있습니다.Secure 플래그를 true로 설정하지 않고 쿠키를 생성합니다.Secure 플래그를 지원합니다. 플래그가 설정되면 브라우저는 HTTPS를 통해 쿠키를 전송하기만 합니다. 암호화되지 않은 채널을 통해 쿠키를 전송하면 네트워크 염탐 공격에 노출될 수 있으므로 안전한 플래그를 사용하는 것이 쿠키의 값 자격 증명을 유지하는 데 도움을 줍니다. 이것은 쿠키가 개인 정보를 포함하거나 세션 ID를 전하는 경우 특히 중요합니다.Secure 플래그를 설정하지 않고 쿠키를 응답에 추가합니다.
...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...
Secure 플래그를 설정하지 않는 경우, HTTPS 요청 중에 전송된 쿠키는 다음 HTTP 요청 중에도 전송됩니다. 그러면 공격자가 암호화되지 않은 네트워크 트래픽을 염탐(무선 네트워크를 통하는 경우 특히 쉬움)하여 쿠키를 손상시킬 수 있습니다.Secure 플래그를 True로 설정하지 않고 쿠키를 생성합니다.Secure 플래그를 지원합니다. 플래그가 설정되면 브라우저는 HTTPS를 통해 쿠키를 전송하기만 합니다. 암호화되지 않은 채널을 통해 쿠키를 전송하면 네트워크 염탐 공격에 노출될 수 있으므로 안전한 플래그를 사용하는 것이 쿠키의 값 자격 증명을 유지하는 데 도움을 줍니다. 이는 쿠키가 개인 데이터 또는 세션 ID를 포함하거나 CSRF 토큰을 전하는 경우 특히 중요합니다.Secure 플래그를 설정하지 않고 쿠키를 응답에 추가합니다.
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("emailCookie", email)
return res
...
Secure 플래그를 설정하지 않는 경우, HTTPS 요청 중에 전송된 쿠키는 다음 HTTP 요청 중에도 전송됩니다. 그러면 공격자가 암호화되지 않은 네트워크 트래픽을 염탐(무선 네트워크를 통하는 경우 특히 쉬움)하여 쿠키를 손상시킬 수 있습니다.true로 설정된 Secure 플래그 없이 쿠키가 생성됩니다.Secure 플래그를 지원합니다. 플래그가 설정되면 브라우저는 HTTPS를 통해 쿠키를 전송하기만 합니다. 암호화되지 않은 채널을 통해 쿠키를 전송하면 네트워크 염탐 공격에 노출될 수 있으므로 안전한 플래그를 사용하는 것이 쿠키의 값 자격 증명을 유지하는 데 도움을 줍니다. 이것은 쿠키가 개인 정보를 포함하거나 세션 ID를 전하는 경우 특히 중요합니다.Secure 플래그 설정 없이 쿠키가 응답에 추가되었습니다.
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, secure = false))
Secure 플래그를 설정하지 않는 경우, HTTPS 요청 중에 전송된 쿠키는 다음 HTTP 요청 중에도 전송됩니다. 암호화되지 않은 무선 연결을 통한 네트워크 트래픽 염탐은 공격자에게는 간단한 작업이므로 HTTP를 통한 쿠키(특히 세션 ID가 있는 쿠키) 전송은 응용 프로그램을 손상시킬 수 있습니다.TRUE로 설정된 NSHTTPCookieSecure 플래그 없이 쿠키가 생성됩니다.Secure 플래그를 지원합니다. 플래그가 설정되면 브라우저는 HTTPS를 통해 쿠키를 전송하기만 합니다. 암호화되지 않은 채널을 통해 쿠키를 전송하면 네트워크 염탐 공격에 노출될 수 있으므로 안전한 플래그를 사용하는 것이 쿠키의 값 자격 증명을 유지하는 데 도움을 줍니다. 이것은 쿠키가 개인 정보를 포함하거나 세션 ID를 전하는 경우 특히 중요합니다.Secure 플래그 설정 없이 쿠키가 응답에 추가되었습니다.
...
let properties = [
NSHTTPCookieDomain: "www.example.com",
NSHTTPCookiePath: "/service",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar"
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
Secure 플래그를 설정하지 않는 경우, HTTPS 요청 중에 전송된 쿠키는 다음 HTTP 요청 중에도 전송됩니다. 암호화되지 않은 무선 연결을 통한 네트워크 트래픽 염탐은 공격자에게는 간단한 작업이므로 HTTP를 통한 쿠키(특히 세션 ID가 있는 쿠키) 전송은 응용 프로그램을 손상시킬 수 있습니다.SameSite 속성을 설정하지 못합니다.SameSite 매개 변수는 요청이 당사자 사이트 또는 동일 사이트 컨텍스트에서 생성되는 경우 쿠키가 해당 요청에만 연결되도록 쿠키의 범위를 제한합니다. 이렇게 하면 CSRF(Cross-Site Request Forgery) 공격으로부터 쿠키를 보호하는 데 도움이 됩니다. SameSite 매개 변수에는 다음과 같은 3가지 값을 사용할 수 있습니다.Strict로 설정하면 최상위 수준 탐색 시에만 요청과 함께 쿠키가 전송됩니다.Lax로 설정하면 동일한 호스트의 최상위 수준 탐색과 타사 사이트에서 호스트로 전송되는 GET 요청에서 쿠키가 전송됩니다. 예를 들어 iframe 또는 href 태그가 있는 타사 사이트에서 호스트 사이트로 연결되는 링크를 누르면 요청에 쿠키가 포함됩니다.SameSite 속성을 None으로 설정합니다.
...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'None');
...
SameSite 속성을 설정하지 못합니다.SameSite 속성은 요청이 당사자 사이트 또는 동일 사이트 컨텍스트에서 생성되는 경우 쿠키가 해당 요청에만 연결되도록 쿠키의 범위를 제한합니다. 이렇게 하면 CSRF(Cross-Site Request Forgery) 공격으로부터 쿠키를 보호하는 데 도움이 됩니다. SameSite 속성에는 다음과 같은 3가지 값을 사용할 수 있습니다.Strict로 설정하면 최상위 수준 탐색 시에만 요청과 함께 쿠키가 전송됩니다.Lax로 설정하면 호스트 사이트에 링크되는 iframe 또는 href 태그가 있는 사이트를 포함하여 타사 사이트에서 발생하는 GET 요청뿐만 아니라 동일한 호스트의 최상위 탐색과 함께 쿠키가 전송됩니다. 요청에 쿠키가 포함됩니다.SameSite 속성을 비활성화합니다.
...
CookieOptions opt = new CookieOptions()
{
SameSite = SameSiteMode.None;
};
context.Response.Cookies.Append("name", "Foo", opt);
...
SameSite 속성을 설정하지 못합니다.SameSite 속성은 요청이 당사자 사이트 또는 동일 사이트 컨텍스트에서 생성되는 경우 쿠키가 해당 요청에만 연결되도록 쿠키의 범위를 제한합니다. 이렇게 하면 CSRF(Cross-Site Request Forgery) 공격으로부터 쿠키를 보호하는 데 도움이 됩니다. SameSite 속성에는 다음과 같은 3가지 값을 사용할 수 있습니다.Strict로 설정하면 최상위 수준 탐색 시에만 요청과 함께 쿠키가 전송됩니다.Lax로 설정하면 동일한 호스트의 최상위 수준 탐색과 타사 사이트에서 호스트로 전송되는 GET 요청에서 쿠키가 전송됩니다. 예를 들어 iframe 또는 href 태그가 있는 타사 사이트에서 호스트 사이트로 연결되는 링크를 누르면 요청에 쿠키가 포함됩니다.SameSite 속성을 비활성화합니다.
c := &http.Cookie{
Name: "cookie",
Value: "samesite-none",
SameSite: http.SameSiteNoneMode,
}
SameSite 속성을 설정하지 못합니다.SameSite 속성은 요청이 당사자 사이트 또는 동일 사이트 컨텍스트에서 생성되는 경우 쿠키가 해당 요청에만 연결되도록 쿠키의 범위를 제한합니다. 이렇게 하면 CSRF(Cross-Site Request Forgery) 공격으로부터 쿠키를 보호하는 데 도움이 됩니다. SameSite 속성에는 다음과 같은 3가지 값을 사용할 수 있습니다.Strict로 설정하면 최상위 수준 탐색 시에만 요청과 함께 쿠키가 전송됩니다.Lax로 설정하면 호스트 사이트에 링크되는 iframe 또는 href 태그가 있는 사이트를 포함하여 타사 사이트에서 발생하는 GET 요청뿐만 아니라 동일한 호스트의 최상위 탐색과 함께 쿠키가 전송됩니다. 예를 들어 iframe 또는 href 태그가 있는 타사 사이트에서 호스트 사이트로 연결되는 링크를 누르면 요청에 쿠키가 포함됩니다.SameSite 속성을 비활성화합니다.
ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue")
...
.sameSite("None")
...
SameSite 속성을 설정하지 못합니다.SameSite 속성은 요청이 당사자 사이트 또는 동일 사이트 컨텍스트에서 생성되는 경우 쿠키가 해당 요청에만 연결되도록 쿠키의 범위를 제한합니다. 이렇게 하면 CSRF(Cross-Site Request Forgery) 공격으로부터 쿠키를 보호하는 데 도움이 됩니다. SameSite 속성에는 다음과 같은 3가지 값을 사용할 수 있습니다.Strict로 설정하면 최상위 수준 탐색 시에만 요청과 함께 쿠키가 전송됩니다.Lax로 설정하면 호스트 사이트에 링크되는 iframe 또는 href 태그가 있는 사이트를 포함하여 타사 사이트에서 발생하는 GET 요청뿐만 아니라 동일한 호스트의 최상위 탐색과 함께 쿠키가 전송됩니다. 예를 들어 iframe 또는 href 태그가 있는 타사 사이트에서 호스트 사이트로 연결되는 링크를 누르면 요청에 쿠키가 포함됩니다.SameSite 속성을 비활성화합니다.
app.get('/', function (req, res) {
...
res.cookie('name', 'Foo', { sameSite: false });
...
}
SameSite 속성을 설정하지 못합니다.SameSite 속성은 요청이 당사자 사이트 또는 동일 사이트 컨텍스트에서 생성되는 경우 쿠키가 해당 요청에만 연결되도록 쿠키의 범위를 제한합니다. 이렇게 하면 CSRF(Cross-Site Request Forgery) 공격으로부터 쿠키를 보호하는 데 도움이 됩니다. SameSite 속성에는 다음과 같은 3가지 값을 사용할 수 있습니다.Strict로 설정하면 최상위 수준 탐색 시에만 요청과 함께 쿠키가 전송됩니다.Lax로 설정하면 동일한 호스트의 최상위 수준 탐색과 타사 사이트에서 호스트로 전송되는 GET 요청에서 쿠키가 전송됩니다. 예를 들어 iframe 또는 href 태그가 있는 타사 사이트에서 호스트 사이트로 연결되는 링크를 누르면 요청에 쿠키가 포함됩니다.SameSite 속성을 비활성화합니다.
ini_set("session.cookie_samesite", "None");
SameSite 속성을 설정하지 못합니다.samesite 매개 변수는 요청이 당사자 사이트 또는 동일 사이트 컨텍스트에서 생성되는 경우 쿠키가 해당 요청에만 연결되도록 쿠키의 범위를 제한합니다. 이렇게 하면 CSRF(Cross-Site Request Forgery) 공격으로부터 쿠키를 보호하는 데 도움이 됩니다. samesite 매개 변수에는 다음과 같은 3가지 값을 사용할 수 있습니다.Strict로 설정하면 최상위 수준 탐색 시에만 요청과 함께 쿠키가 전송됩니다.Lax로 설정하면 동일한 호스트의 최상위 수준 탐색과 타사 사이트에서 호스트로 전송되는 GET 요청에서 쿠키가 전송됩니다. 예를 들어 iframe 또는 href 태그가 있는 타사 사이트에서 호스트 사이트로 연결되는 링크를 누르면 요청에 쿠키가 포함됩니다.SameSite 속성을 비활성화합니다.
response.set_cookie("cookie", value="samesite-none", samesite=None)
/")에서 액세스할 수 있도록 쿠키를 설정합니다. 그러면 도메인의 모든 웹 응용 프로그램에 대해 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://communitypages.example.com/MyForum에서 배포된 포럼 응용 프로그램이 있고 이 응용 프로그램이 사용자가 포럼에 로그인할 때 "/" 경로를 사용하여 세션 ID 쿠키를 설정한다고 가정합니다. 예를 들어, 다음과 같습니다.
...
String path = '/';
Cookie cookie = new Cookie('sessionID', sessionID, path, maxAge, true, 'Strict');
...
http://communitypages.example.com/EvilSite에서 다른 응용 프로그램을 생성하여 포럼에서 이 사이트에 대한 링크를 게시한다고 가정하겠습니다. 포럼의 사용자가 이 링크를 클릭하면 브라우저는 /MyForum에서 설정된 쿠키를 /EvilSite에서 실행 중인 응용 프로그램으로 전송합니다. 공격자는 세션 ID를 도용하여 /EvilSite를 방문한 임의의 포럼 사용자 계정을 손상시킬 수 있습니다./EvilSite를 사용한 쿠키 감염 공격을 수행하여 자체적으로 /MyForum의 쿠키를 덮어쓰는 광범위한 쿠키를 생성할 수도 있습니다./"가 되도록 쿠키를 설정하지만 그렇게 하면 동일한 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://communitypages.example.com/MyForum에서 배포된 포럼 응용 프로그램이 있고 이 응용 프로그램이 사용자가 포럼에 로그인할 때 "/" 경로를 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.
HttpCookie cookie = new HttpCookie("sessionID", sessionID);
cookie.Path = "/";
http://communitypages.example.com/EvilSite에서 다른 응용 프로그램을 생성하여 포럼에서 이 사이트에 대한 링크를 게시한다고 가정하겠습니다. 포럼의 사용자가 이 링크를 클릭하면 브라우저는 /MyForum에서 설정된 쿠키를 /EvilSite에서 실행 중인 응용 프로그램으로 전송합니다. 공격자는 세션 ID를 도용하여 /EvilSite를 방문한 임의의 포럼 사용자 계정을 손상시킬 수 있습니다./EvilSite을 사용한 Cookie Poisoning 공격을 수행하여 /MyForum의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다./")에서 액세스할 수 있도록 쿠키를 설정합니다. 그러면 도메인의 모든 웹 응용 프로그램에 대해 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://communitypages.example.com/MyForum에서 배포된 포럼 응용 프로그램이 있고 이 응용 프로그램이 사용자가 포럼에 로그인할 때 "/" 경로를 사용하여 세션 ID 쿠키를 설정한다고 가정하겠습니다.
cookie := http.Cookie{
Name: "sessionID",
Value: sID,
Expires: time.Now().AddDate(0, 0, 1),
Path: "/",
}
...
http://communitypages.example.com/EvilSite에서 다른 응용 프로그램을 생성하여 포럼에서 이 사이트에 대한 링크를 게시한다고 가정하겠습니다. 포럼의 사용자가 이 링크를 클릭하면 브라우저는 /MyForum에서 설정된 쿠키를 /EvilSite에서 실행 중인 응용 프로그램으로 전송합니다. 공격자는 세션 ID를 도용하여 /EvilSite를 방문한 임의의 포럼 사용자 계정을 손상시킬 수 있습니다./EvilSite를 사용한 "쿠키 감염(Cookie Poisoning) 공격"을 수행하여 /MyForum의 쿠키를 덮어쓰는, 지나치게 광범위한 자체 쿠키를 생성할 수 있습니다./")에서 액세스할 수 있도록 쿠키를 설정합니다. 그러면 도메인의 모든 웹 응용 프로그램에 대해 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://communitypages.example.com/MyForum에서 배포된 포럼 응용 프로그램이 있고 이 응용 프로그램이 사용자가 포럼에 로그인할 때 "/" 경로를 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.
Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setPath("/");
http://communitypages.example.com/EvilSite에서 다른 응용 프로그램을 생성하여 포럼에서 이 사이트에 대한 링크를 게시한다고 가정하겠습니다. 포럼의 사용자가 이 링크를 클릭하면 브라우저는 /MyForum에서 설정된 쿠키를 /EvilSite에서 실행 중인 응용 프로그램으로 전송합니다. 공격자는 세션 ID를 도용하여 /EvilSite를 방문한 임의의 포럼 사용자 계정을 손상시킬 수 있습니다./EvilSite을 사용한 Cookie Poisoning 공격을 수행하여 /MyForum의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다./")에서 액세스할 수 있도록 쿠키를 설정합니다. 그러면 도메인의 모든 웹 응용 프로그램에 대해 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://communitypages.example.com/MyForum에서 배포된 포럼 응용 프로그램이 있고 이 응용 프로그램이 사용자가 포럼에 로그인할 때 "/" 경로를 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.
cookie_options = {};
cookie_options.path = '/';
...
res.cookie('important_cookie', info, cookie_options);
http://communitypages.example.com/EvilSite에서 다른 응용 프로그램을 생성하여 포럼에서 이 사이트에 대한 링크를 게시한다고 가정하겠습니다. 포럼의 사용자가 이 링크를 클릭하면 브라우저는 /MyForum에서 설정된 쿠키를 /EvilSite에서 실행 중인 응용 프로그램으로 전송합니다. 공격자는 세션 ID를 도용하여 /EvilSite를 방문한 임의의 포럼 사용자 계정을 손상시킬 수 있습니다./EvilSite을 사용한 Cookie Poisoning 공격을 수행하여 /MyForum의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다./")에서 액세스할 수 있도록 쿠키를 설정합니다. 그러면 도메인의 모든 웹 응용 프로그램에 대해 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://communitypages.example.com/MyForum에서 배포된 포럼 응용 프로그램이 있고 이 응용 프로그램이 사용자가 포럼에 로그인할 때 "/" 경로를 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
[cookieProperties setValue:@"/" forKey:NSHTTPCookiePath];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
http://communitypages.example.com/EvilSite에서 다른 응용 프로그램을 생성하여 포럼에서 이 사이트에 대한 링크를 게시한다고 가정하겠습니다. 포럼의 사용자가 이 링크를 클릭하면 브라우저는 /MyForum에서 설정된 쿠키를 /EvilSite에서 실행 중인 응용 프로그램으로 전송합니다. 공격자는 세션 ID를 도용하여 /EvilSite를 방문한 임의의 포럼 사용자 계정을 손상시킬 수 있습니다./EvilSite을 사용한 Cookie Poisoning 공격을 수행하여 /MyForum의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다./")에서 액세스할 수 있도록 쿠키를 설정합니다. 그러면 도메인의 모든 웹 응용 프로그램에 대해 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://communitypages.example.com/MyForum에서 배포된 포럼 응용 프로그램이 있고 이 응용 프로그램이 사용자가 포럼에 로그인할 때 "/" 경로를 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.
setcookie("mySessionId", getSessionID(), 0, "/", "communitypages.example.com", true, true);
http://communitypages.example.com/EvilSite에서 다른 응용 프로그램을 생성하여 포럼에서 이 사이트에 대한 링크를 게시한다고 가정하겠습니다. 포럼의 사용자가 이 링크를 클릭하면 브라우저는 /MyForum에서 설정된 쿠키를 /EvilSite에서 실행 중인 응용 프로그램으로 전송합니다. 공격자는 세션 ID를 도용하여 /EvilSite를 방문한 임의의 포럼 사용자 계정을 손상시킬 수 있습니다./EvilSite을 사용한 Cookie Poisoning 공격을 수행하여 /MyForum의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다./")에서 액세스할 수 있도록 쿠키를 설정합니다. 그러면 도메인의 모든 웹 응용 프로그램에 대해 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://communitypages.example.com/MyForum에서 배포된 포럼 응용 프로그램이 있고 이 응용 프로그램이 사용자가 포럼에 로그인할 때 "/" 경로를 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("sessionid", value) # Path defaults to "/"
return res
...
http://communitypages.example.com/EvilSite에서 다른 응용 프로그램을 생성하여 포럼에서 이 사이트에 대한 링크를 게시한다고 가정하겠습니다. 포럼의 사용자가 이 링크를 클릭하면 브라우저는 /MyForum에서 설정된 쿠키를 /EvilSite에서 실행 중인 응용 프로그램으로 전송합니다. 공격자는 세션 ID를 도용하여 /EvilSite를 방문한 임의의 포럼 사용자 계정을 손상시킬 수 있습니다./EvilSite를 사용한 "쿠키 감염(Cookie Poisoning) 공격"을 수행하여 /MyForum의 쿠키를 덮어쓰는, 지나치게 광범위한 자체 쿠키를 생성할 수도 있습니다./")에서 액세스할 수 있도록 쿠키를 설정합니다. 그러면 도메인의 모든 웹 응용 프로그램에 대해 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://communitypages.example.com/MyForum에서 배포된 포럼 응용 프로그램이 있고 이 응용 프로그램이 사용자가 포럼에 로그인할 때 "/" 경로를 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, path = "/"))
http://communitypages.example.com/EvilSite에서 다른 응용 프로그램을 생성하여 포럼에서 이 사이트에 대한 링크를 게시한다고 가정하겠습니다. 포럼의 사용자가 이 링크를 클릭하면 브라우저는 /MyForum에서 설정된 쿠키를 /EvilSite에서 실행 중인 응용 프로그램으로 전송합니다. 공격자는 세션 ID를 도용하여 /EvilSite를 방문한 임의의 포럼 사용자 계정을 손상시킬 수 있습니다./EvilSite을 사용한 Cookie Poisoning 공격을 수행하여 /MyForum의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다./")에서 액세스할 수 있도록 쿠키를 설정합니다. 그러면 도메인의 모든 웹 응용 프로그램에 대해 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://communitypages.example.com/MyForum에서 배포된 포럼 응용 프로그램이 있고 이 응용 프로그램이 사용자가 포럼에 로그인할 때 "/" 경로를 사용하여 세션 ID 쿠키를 설정한다고 가정합니다.
...
let properties = [
NSHTTPCookieDomain: "www.example.com",
NSHTTPCookiePath: "/",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar",
NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
http://communitypages.example.com/EvilSite에서 다른 응용 프로그램을 생성하여 포럼에서 이 사이트에 대한 링크를 게시한다고 가정하겠습니다. 포럼의 사용자가 이 링크를 클릭하면 브라우저는 /MyForum에서 설정된 쿠키를 /EvilSite에서 실행 중인 응용 프로그램으로 전송합니다. 공격자는 세션 ID를 도용하여 /EvilSite를 방문한 임의의 포럼 사용자 계정을 손상시킬 수 있습니다./EvilSite을 사용한 Cookie Poisoning 공격을 수행하여 /MyForum의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다.SameSite 매개 변수가 Strict로 설정되지 않았습니다.SameSite 매개 변수는 요청이 당사자 사이트 또는 동일 사이트 컨텍스트에서 생성되는 경우 쿠키가 해당 요청에만 연결되도록 쿠키의 범위를 제한합니다. 이렇게 하면 CSRF(Cross-Site Request Forgery) 공격으로부터 쿠키를 보호하는 데 도움이 됩니다. SameSite 매개 변수에는 다음과 같은 3가지 값을 사용할 수 있습니다.Strict로 설정하면 최상위 수준 탐색 시에만 요청과 함께 쿠키가 전송됩니다.Lax로 설정하면 동일한 호스트의 최상위 수준 탐색과 타사 사이트에서 호스트로 전송되는 GET 요청에서 쿠키가 전송됩니다. 예를 들어 iframe 또는 href 태그가 있는 타사 사이트에서 호스트 사이트로 연결되는 링크를 누르면 요청에 쿠키가 포함됩니다.SameSite 매개 변수를 Lax로 설정합니다.
...
Cookie cookie = new Cookie('name', 'Foo', path, -1, true, 'Lax');
...
SameSite 속성이 Strict로 설정되지 않았습니다.SameSite 속성은 CSRF(Cross-Site Request Forgery)와 같은 공격으로부터 쿠키를 보호합니다. 세션 쿠키는 사이트에 사용자에 대한 정보를 보여줌으로써 해당 사용자가 권한이 부여된 작업을 수행할 수 있도록 합니다. 그러나 이 브라우저는 요청과 함께 자동으로 쿠키를 전송하므로 사용자 및 웹 사이트가 권한 부여 시 브라우저를 묵시적으로 신뢰합니다. 공격자는 공격자가 제어하는 타사 사이트 페이지에서 href 및 src 태그 속성(예: link 및 iframe) 안에 링크를 포함하는 방법으로 이 신뢰를 남용하고 사용자 대신 사이트에 요청을 제출할 수 있습니다. 공격자가 자신이 제어하는 타사 사이트로 의심하지 않는 사용자를 유인할 수 있는 경우 공격자는 사용자에게 권한을 부여하는 세션 쿠키를 자동으로 포함하는 요청을 제출하여 실질적으로 공격자가 사용자인 것처럼 공격자에게 권한을 부여할 수 있습니다.SameSite 속성 값을 Strict로 설정하십시오. 이렇게 하면 최상위 탐색 요청이거나 동일한 사이트에서 시작된 요청에만 쿠키를 추가하도록 브라우저가 제한됩니다. iframe, img 및 form과 같은 다양한 태그의 링크를 통해 타사 사이트에서 시작되는 요청에는 이러한 쿠키가 없으므로 사이트에서 권한이 부여되지 않은 사용자에 대해 조치를 취할 수 없습니다.SameSite 속성 값을 Lax로 설정합니다.
...
CookieOptions opt = new CookieOptions()
{
SameSite = SameSiteMode.Lax;
};
context.Response.Cookies.Append("name", "Foo", opt);
...
SameSite 속성이 SameSiteStrictMode로 설정되지 않았습니다.SameSite 속성은 CSRF(Cross-Site Request Forgery)와 같은 공격으로부터 쿠키를 보호합니다. 세션 쿠키는 사이트에 사용자에 대한 정보를 보여줌으로써 해당 사용자가 권한이 부여된 작업을 수행할 수 있도록 합니다. 그러나 이 브라우저는 요청과 함께 자동으로 쿠키를 전송하므로 사용자 및 웹 사이트가 권한 부여 시 브라우저를 묵시적으로 신뢰합니다. 공격자는 공격자가 제어하는 타사 사이트 페이지에서 href 및 src 태그 속성(예: link 및 iframe) 안에 링크를 포함하는 방법으로 이 신뢰를 남용하고 사용자 대신 사이트에 요청을 제출할 수 있습니다. 공격자가 자신이 제어하는 타사 사이트로 의심하지 않는 사용자를 유인할 수 있는 경우 공격자는 사용자에게 권한을 부여하는 세션 쿠키를 자동으로 포함하는 요청을 제출하여 실질적으로 공격자가 사용자인 것처럼 공격자에게 권한을 부여할 수 있습니다.SameSite 속성을 SameSiteStrictMode로 설정하면 최상위 수준 탐색인 요청 또는 동일한 사이트에서 시작된 요청에만 쿠키를 추가하도록 브라우저가 제한됩니다. iframe, img 및 form과 같은 다양한 태그의 링크를 통해 타사 사이트에서 시작되는 요청에는 이러한 쿠키가 없으므로 사이트에서 권한이 부여되지 않은 사용자에 대해 조치를 취할 수 없습니다.SameSite 속성에서 SameSiteLaxMode를 활성화합니다.
c := &http.Cookie{
Name: "cookie",
Value: "samesite-lax",
SameSite: http.SameSiteLaxMode,
}
SameSite 속성이 Strict로 설정되지 않았습니다.SameSite 속성은 CSRF(Cross-Site Request Forgery)와 같은 공격으로부터 쿠키를 보호합니다. 세션 쿠키는 사이트에 사용자에 대한 정보를 보여줌으로써 해당 사용자가 권한이 부여된 작업을 수행할 수 있도록 합니다. 그러나 이 브라우저는 요청과 함께 자동으로 쿠키를 전송하므로 사용자 및 웹 사이트가 권한 부여 시 브라우저를 묵시적으로 신뢰합니다. 공격자는 공격자가 제어하는 타사 사이트 페이지에서 href 및 src 태그 속성(예: link 및 iframe) 안에 링크를 포함하는 방법으로 이 신뢰를 남용하고 사용자 대신 사이트에 요청을 제출할 수 있습니다. 공격자가 자신이 제어하는 타사 사이트로 의심하지 않는 사용자를 유인할 수 있는 경우 공격자는 사용자에게 권한을 부여하는 세션 쿠키를 자동으로 포함하는 요청을 제출하여 실질적으로 공격자가 사용자인 것처럼 공격자에게 권한을 부여할 수 있습니다.SameSite 속성 값을 Strict로 설정하십시오. 이렇게 하면 최상위 탐색 요청이거나 동일한 사이트에서 시작된 요청에만 쿠키를 추가하도록 브라우저가 제한됩니다. iframe, img 및 form과 같은 다양한 태그의 링크를 통해 타사 사이트에서 시작되는 요청에는 이러한 쿠키가 없으므로 사이트에서 권한이 부여되지 않은 사용자에 대해 조치를 취할 수 없습니다.SameSite 속성 값을 Lax로 설정합니다.
ResponseCookie cookie = ResponseCookie.from("myCookie", "myCookieValue")
...
.sameSite("Lax")
...
}
SameSite 속성이 Strict로 설정되지 않았습니다.SameSite 속성은 CSRF(Cross-Site Request Forgery)와 같은 공격으로부터 쿠키를 보호합니다. 세션 쿠키는 사이트에 사용자에 대한 정보를 보여줌으로써 해당 사용자가 권한이 부여된 작업을 수행할 수 있도록 합니다. 그러나 이 브라우저는 요청과 함께 자동으로 쿠키를 전송하므로 사용자 및 웹 사이트가 권한 부여 시 브라우저를 묵시적으로 신뢰합니다. 공격자는 공격자가 제어하는 타사 사이트 페이지에서 href 및 src 태그 속성(예: link 및 iframe) 안에 링크를 포함하는 방법으로 이 신뢰를 남용하고 사용자 대신 사이트에 요청을 제출할 수 있습니다. 공격자가 자신이 제어하는 타사 사이트로 의심하지 않는 사용자를 유인할 수 있는 경우 공격자는 사용자에게 권한을 부여하는 세션 쿠키를 자동으로 포함하는 요청을 제출하여 실질적으로 공격자가 사용자인 것처럼 공격자에게 권한을 부여할 수 있습니다.SameSite 속성 값을 Strict로 설정하십시오. 이렇게 하면 최상위 탐색 요청이거나 동일한 사이트에서 시작된 요청에만 쿠키를 추가하도록 브라우저가 제한됩니다. iframe, img 및 form과 같은 다양한 태그의 링크를 통해 타사 사이트에서 시작되는 요청에는 이러한 쿠키가 없으므로 사이트에서 권한이 부여되지 않은 사용자에 대해 조치를 취할 수 없습니다.SameSite 속성 값을 Lax로 설정합니다.
app.get('/', function (req, res) {
...
res.cookie('name', 'Foo', { sameSite: "Lax" });
...
}
SameSite 속성이 Strict로 설정되지 않았습니다.SameSite 속성은 CSRF(Cross-Site Request Forgery)와 같은 공격으로부터 쿠키를 보호합니다. 세션 쿠키는 사이트에 사용자에 대한 정보를 보여줌으로써 해당 사용자가 권한이 부여된 작업을 수행할 수 있도록 합니다. 그러나 이 브라우저는 요청과 함께 자동으로 쿠키를 전송하므로 사용자 및 웹 사이트가 권한 부여 시 브라우저를 묵시적으로 신뢰합니다. 공격자는 공격자가 제어하는 타사 사이트 페이지에서 href 및 src 태그 속성(예: link 및 iframe) 안에 링크를 포함하는 방법으로 이 신뢰를 남용하고 사용자 대신 사이트에 요청을 제출할 수 있습니다. 공격자가 자신이 제어하는 타사 사이트로 의심하지 않는 사용자를 유인할 수 있는 경우 공격자는 사용자에게 권한을 부여하는 세션 쿠키를 자동으로 포함하는 요청을 제출하여 실질적으로 공격자가 사용자인 것처럼 공격자에게 권한을 부여할 수 있습니다.SameSite 속성을 Strict로 설정하면 최상위 수준 탐색인 요청 또는 동일한 사이트에서 시작된 요청에만 쿠키를 추가하도록 브라우저가 제한됩니다. iframe, img 및 form과 같은 다양한 태그의 링크를 통해 타사 사이트에서 시작되는 요청에는 이러한 쿠키가 없으므로 사이트에서 권한이 부여되지 않은 사용자에 대해 조치를 취할 수 없습니다.SameSite 속성에서 Lax 모드를 활성화합니다.
ini_set("session.cookie_samesite", "Lax");
SameSite 속성이 Strict로 설정되지 않았습니다.SameSite 속성은 CSRF(Cross-Site Request Forgery)와 같은 공격으로부터 쿠키를 보호합니다. 세션 쿠키는 사이트에 사용자에 대한 정보를 보여줌으로써 해당 사용자가 권한이 부여된 작업을 수행할 수 있도록 합니다. 그러나 이 브라우저는 요청과 함께 자동으로 쿠키를 전송하므로 사용자 및 웹 사이트가 권한 부여 시 브라우저를 묵시적으로 신뢰합니다. 공격자는 공격자가 제어하는 타사 사이트 페이지에서 href 및 src 태그 속성(예: link 및 iframe) 안에 링크를 포함하는 방법으로 이 신뢰를 남용하고 사용자 대신 사이트에 요청을 제출할 수 있습니다. 공격자는 자신이 제어하는 타사 사이트로 의심하지 않는 사용자를 유인하는 경우 사용자에게 권한을 부여하는 세션 쿠키를 자동으로 포함하는 요청을 실행할 수 있습니다. 그러면 실질적으로 공격자가 사용자인 것처럼 액세스 권한이 부여됩니다.SameSite 매개 변수에서 세션 쿠키를 Strict로 설정하면 최상위 수준 탐색인 요청 또는 동일한 사이트에서 시작된 요청에만 쿠키를 추가하도록 브라우저가 제한됩니다. iframe, img 및 form과 같은 다양한 태그의 링크를 통해 타사 사이트에서 시작되는 요청에는 이러한 쿠키가 없으므로 사이트에서 권한이 부여되지 않은 사용자에 대해 조치를 취할 수 없습니다.samesite 속성에서 Lax를 활성화합니다.
response.set_cookie("cookie", value="samesite-lax", samesite="Lax")
...
Integer maxAge = 60*60*24*365*10;
Cookie cookie = new Cookie('emailCookie', emailCookie, path, maxAge, true, 'Strict');
...
HttpCookie cookie = new HttpCookie("emailCookie", email);
cookie.Expires = DateTime.Now.AddYears(10);;
Cookie cookie = new Cookie("emailCookie", email);
cookie.setMaxAge(60*60*24*365*10);
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
[cookieProperties setValue:[[NSDate date] dateByAddingTimeInterval:(60*60*24*365*10)] forKey:NSHTTPCookieExpires];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
setcookie("emailCookie", $email, time()+60*60*24*365*10);
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("emailCookie", email, expires=time()+60*60*24*365*10, secure=True, httponly=True)
return res
...
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, maxAge = Some(60*60*24*365*10)))
...
let properties = [
NSHTTPCookieDomain: "www.example.com",
NSHTTPCookiePath: "/service",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar",
NSHTTPCookieSecure: true,
NSHTTPCookieExpires : NSDate(timeIntervalSinceNow: (60*60*24*365*10))
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
MyAccountActions 및 페이지 작업 메서드 pageAction()을 선언합니다. pageAction() 메서드는 페이지 URL 방문 시에 실행되며 서버는 CSRF 토큰 유무를 확인하지 않습니다.
<apex:page controller="MyAccountActions" action="{!pageAction}">
...
</apex:page>
public class MyAccountActions {
...
public void pageAction() {
Map<String,String> reqParams = ApexPages.currentPage().getParameters();
if (params.containsKey('id')) {
Id id = reqParams.get('id');
Account acct = [SELECT Id,Name FROM Account WHERE Id = :id];
delete acct;
}
}
...
}
<img src="http://my-org.my.salesforce.com/apex/mypage?id=YellowSubmarine" height=1 width=1/>
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "/new_user");
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
rb.sendRequest(body, new NewAccountCallback(callback));
RequestBuilder rb = new RequestBuilder(RequestBuilder.POST, "http://www.example.com/new_user");
body = addToPost(body, "attacker";
body = addToPost(body, "haha");
rb.sendRequest(body, new NewAccountCallback(callback));
example.com의 관리자가 사이트에서 세션을 활성화한 상태에서 악성 페이지를 방문하는 경우 무의식적으로 공격자를 위한 계정을 만들게 됩니다. 이것이 CSRF 공격입니다. 이 공격이 가능한 이유는 응용 프로그램에 해당 요청의 출처를 확인할 방법이 없기 때문입니다. 모든 요청은 사용자가 선택한 적법한 작업이거나 공격자가 설정한 허위 작업일 가능성이 있습니다. 공격자는 허위 요청이 생성하는 웹 페이지를 보지 못하므로 이 공격 기법은 응용 프로그램의 상태를 변경하는 요청의 경우에만 유용합니다.
<http auto-config="true">
...
<csrf disabled="true"/>
</http>
var req = new XMLHttpRequest();
req.open("POST", "/new_user", true);
body = addToPost(body, new_username);
body = addToPost(body, new_passwd);
req.send(body);
var req = new XMLHttpRequest();
req.open("POST", "http://www.example.com/new_user", true);
body = addToPost(body, "attacker");
body = addToPost(body, "haha");
req.send(body);
example.com의 관리자가 사이트에서 세션을 활성화한 상태에서 악성 페이지를 방문하는 경우 무의식적으로 공격자를 위한 계정을 만들게 됩니다. 이것이 CSRF 공격입니다. 이는 응용 프로그램이 해당 요청의 출처를 확인하는 방법을 가지고 있지 않기 때문입니다. 모든 요청은 사용자가 선택한 적법한 작업이거나 공격자가 설정한 허위 작업일 가능성이 있습니다. 공격자는 허위 요청이 생성하는 웹 페이지를 보지 못하므로 이 공격 기법은 응용 프로그램의 상태를 변경하는 요청의 경우에만 유용합니다.
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
example.com의 관리자가 사이트에서 세션을 활성화한 상태에서 악성 페이지를 방문하는 경우 무의식적으로 공격자를 위한 계정을 만들게 됩니다. 이것이 CSRF 공격입니다. 이는 응용 프로그램이 해당 요청의 출처를 확인하는 방법을 가지고 있지 않기 때문입니다. 모든 요청은 사용자가 선택한 적법한 작업이거나 공격자가 설정한 허위 작업일 가능성이 있습니다. 공격자는 허위 요청이 생성하는 웹 페이지를 보지 못하므로 이 공격 기법은 응용 프로그램의 상태를 변경하는 요청의 경우에만 유용합니다.buyItem 컨트롤러 메서드에 대한 CSRF 보호를 비활성화합니다.
+ nocsrf
POST /buyItem controllers.ShopController.buyItem
shop.com의 활성 세션에 있는 동안 악성 페이지를 방문하게 되면 의도치 않게 공격자의 물품을 구입하게 됩니다. 이것이 CSRF 공격입니다. 이 공격이 가능한 이유는 응용 프로그램에 해당 요청의 출처를 확인할 방법이 없기 때문입니다. 모든 요청은 사용자가 선택한 적법한 작업이거나 공격자가 설정한 허위 작업일 가능성이 있습니다. 공격자는 허위 요청이 생성하는 웹 페이지를 보지 못하므로 이 공격 기법은 응용 프로그램의 상태를 변경하는 요청의 경우에만 유용합니다.
<form method="POST" action="/new_user" >
Name of new user: <input type="text" name="username">
Password for new user: <input type="password" name="user_passwd">
<input type="submit" name="action" value="Create User">
</form>
<form method="POST" action="http://www.example.com/new_user">
<input type="hidden" name="username" value="hacker">
<input type="hidden" name="user_passwd" value="hacked">
</form>
<script>
document.usr_form.submit();
</script>
example.com의 관리자가 사이트에서 세션을 활성화한 상태에서 악성 페이지를 방문하는 경우 무의식적으로 공격자를 위한 계정을 만들게 됩니다. 이것이 CSRF 공격입니다. 이는 응용 프로그램이 해당 요청의 출처를 확인하는 방법을 가지고 있지 않기 때문입니다. 모든 요청은 사용자가 선택한 적법한 작업이거나 공격자가 설정한 허위 작업일 가능성이 있습니다. 공격자는 허위 요청이 생성하는 웹 페이지를 보지 못하므로 이 공격 기법은 응용 프로그램의 상태를 변경하는 요청의 경우에만 유용합니다.
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...
name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 응용 프로그램이 콘텐트를 분명하게 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.eid를 읽어 사용자에게 표시합니다.
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
Example 1에서처럼 이 코드는 eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + name;
}
name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 응용 프로그램이 콘텐트를 분명하게 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.eid를 읽어 사용자에게 표시합니다.
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...
Example 1에서처럼 이 코드는 eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
name의 값이 제대로 정의된 경우(예: 영숫자)에 올바르게 작동하지만, 악성 데이터를 확인하기 위한 작업은 수행하지 않습니다. 데이터베이스에서 읽는 경우에도, 데이터베이스의 콘텐트가 사용자가 제공하는 데이터에서 제공될 수 있기 때문에 값을 적절하게 확인해야 합니다. 이러한 방식으로 공격자는 Reflected XSS에서처럼 피해자와 상호 작용할 필요 없이 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. Stored XSS(또는 Persistent)로 알려진 이런 공격 유형은, 데이터가 취약한 기능에 간접적으로 제공되므로 감지하기 매우 어려울 수 있으며, 여러 사용자에게 영향을 줄 수 있으므로 더 큰 영향을 미칠 수도 있습니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.username)를 읽고 사용자에게 표시합니다.
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username에 메타 문자 또는 소스 코드가 포함되어 있으면 웹 브라우저에 의해 실행됩니다.Example 1에서처럼 데이터베이스 또는 다른 데이터 저장소는 동적 콘텐트에 포함될 위험한 데이터를 응용 프로그램에 제공할 수 있습니다. 공격자의 관점에서 악성 콘텐트를 저장할 최적의 장소는 모든 사용자 특히 높은 권한을 가진 사용자(민감한 정보를 처리하고 중요한 작업을 수행할 가능성이 높은 사용자)가 액세스할 수 있는 장소입니다.Example 2에서처럼 데이터를 HTTP 요청에서 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. Reflected XSS는 공격자가 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공한 후 사용자에게 다시 적용하여 사용자의 브라우저에 의해 실행될 때 발생합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 공개적으로 게시되거나 피해자에게 직접 전자 메일로 전송되는 URL의 매개 변수로 악성 콘텐트를 포함하는 것입니다. 이러한 방식으로 생성된 URL은 공격자가 피해자를 속여 해당 URL을 방문하게 하는 많은 피싱 기법의 근간을 이룹니다. 사이트가 콘텐트를 사용자에게 다시 적용한 후, 해당 콘텐트가 실행되고 민감한 개인 정보 전달, 피해자 컴퓨터에서 권한이 없는 작업 실행 등과 같은 여러 작업을 수행할 수 있습니다.
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>
EmployeeName은 다음과 같이 정의된 폼 컨트롤입니다.예제 2: 다음 ASP.NET 코드 세그먼트는
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 1과 기능적으로 동일하지만 프로그래밍 방식으로 모든 form elements를 구현합니다.
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 응용 프로그램이 콘텐트를 분명하게 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 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에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 3 및 Example 4에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
ENAME의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 ENAME의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 ENAME의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Stored XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.EID를 읽어 사용자에게 표시합니다.
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
Example 1에서처럼 이 코드는 EID에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. EID가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. 공격자가 다음을 수행하는 경우 저장된 XSS 악용 발생 Example 2에서처럼 데이터를 HTML 폼에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 응용 프로그램이 콘텐트를 분명하게 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.eid를 읽어 사용자에게 표시합니다.
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Example 1에서처럼 이 코드는 Form.eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. Form.eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.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(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서 볼 수 있듯이 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 반영합니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서 볼 수 있듯이 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.
<%...
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 %>
name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 응용 프로그램이 콘텐트를 분명하게 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.eid를 읽어 사용자에게 표시합니다.
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
Example 1에서처럼 이 코드는 eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
...
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 내에 있는 웹 페이지의 컨텍스트에서 실행됩니다.Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 3과 같이 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.
var http = require('http');
...
function listener(request, response){
connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
if (!err && rows.length > 0){
response.write('<p>Welcome, ' + rows[0].name + '!</p>');
}
...
});
...
}
...
http.createServer(listener).listen(8080);
name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 응용 프로그램이 콘텐트를 분명하게 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.eid를 읽고 사용자에게 표시합니다.
var http = require('http');
var url = require('url');
...
function listener(request, response){
var eid = url.parse(request.url, true)['query']['eid'];
if (eid !== undefined){
response.write('<p>Welcome, ' + eid + '!</p>');
}
...
}
...
http.createServer(listener).listen(8080);
Example 1에서처럼 이 코드는 eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.
...
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()
...
name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 응용 프로그램이 콘텐트를 분명하게 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.eid를 읽은 다음 서블릿의 응답에서 사용자에게 값을 되돌려 주어 표시합니다.
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
Example 1에서처럼 이 코드는 eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
...
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 내에 있는 웹 페이지의 컨텍스트에서 실행됩니다.Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 3과 같이 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.myapp://input_to_the_application). 그런 다음 URL의 신뢰할 수 없는 데이터가 UIWebView 구성 요소의 HTML 출력을 렌더링하는 데 사용됩니다.
...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]
...
Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 2에서처럼 데이터는 사용자 지정 URL 스키마에서 직접 읽어 들여 UIWebView 응답의 콘텐트에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 iOS 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 사용자 지정 스키마 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 취약한 응용 프로그램을 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 앱이 공격자의 컨텐츠를 사용자에게 보내면, 컨텐츠가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.
<?php...
$con = mysql_connect($server,$user,$password);
...
$result = mysql_query("select * from emp where id="+eid);
$row = mysql_fetch_array($result)
echo 'Employee name: ', mysql_result($row,0,'name');
...
?>
name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 응용 프로그램이 콘텐트를 분명하게 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.eid를 읽어 사용자에게 표시합니다.
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
Example 1에서처럼 이 코드는 eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || name || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 응용 프로그램이 콘텐트를 분명하게 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.eid를 읽어 사용자에게 표시합니다.
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || eid || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1에서처럼 이 코드는 eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.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(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.eid를 읽어 사용자에게 표시합니다.
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
Example 1에서처럼 코드는 eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.Rack::Request#params()를 Example 2에서처럼 사용하는 경우에는 GET 매개 변수와 POST 매개 변수가 모두 있으므로 URL에 악의적인 코드가 추가되는 것 외에도 다양한 유형의 공격에 취약해질 수 있습니다.Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.eid를 읽어 사용자에게 표시합니다.
def getEmployee = Action { implicit request =>
val employee = getEmployeeFromDB()
val eid = employee.id
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 내의 텍스트에 표준 영숫자 텍스트만 있으면 문제없이 작동합니다. inputTextField 내의 텍스트에 메타 문자나 소스 코드가 포함되어 있으면 웹 브라우저에서 HTTP 응답을 표시할 때 입력을 코드로 실행할 수 있습니다.myapp://input_to_the_application). 그런 다음 URL의 신뢰할 수 없는 데이터가 UIWebView 구성 요소의 HTML 출력을 렌더링하는 데 사용됩니다.
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
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
}
...
Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 2에서는 데이터를 사용자가 제어할 수 있는 UI 구성 요소에서 직접 읽어 들여 HTTP 응답에 다시 적용합니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 3에서는 대상 응용 프로그램 외부의 소스에서 대상 응용 프로그램의 사용자 지정 URL 스키마를 사용하여 URL 요청을 생성하고, 이어서 URL 요청의 확인되지 않은 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 다시 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & objADORecordSet("name")
objADORecordSet.MoveNext
Wend
...
name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 응용 프로그램이 콘텐트를 분명하게 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.eid를 읽어 사용자에게 표시합니다.
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
Example 1에서처럼 이 코드는 eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.cl_http_utility=>escape_html과 같은 특정 인코딩 함수 모듈을 사용하면 일부 cross-site scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 함수 모듈을 사용하는 것은 약한 거부 목록을 사용하여 cross-site scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Secure Coding Rulepacks는 인코딩이 적용되는 경우에도 cross-site scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.eid를 읽고 HTML 인코딩하여 사용자에게 표시합니다.
...
eid = request->get_form_field( 'eid' ).
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = eid
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_eid.
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( e_eid ).
...
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
CALL METHOD cl_http_utility=>escape_html
EXPORTING
UNESCAPED = itab_employees-name
KEEP_NUM_CHAR_REF = '-'
RECEIVING
ESCAPED = e_name.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( e_name ).
...
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.eid를 읽고 HTML 인코딩하여 사용자에게 표시합니다.
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + escape(eid);
...
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + escape(name);
}
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!HTMLENCODE(variable)}'">Click me!</div>
HTMLENCODE의 사용에도 불구하고, 데이터베이스에서 제공하는 데이터를 적절하게 확인하지 않으며 XSS에 취약합니다. 이는 variable 콘텐트가 서로 다른 메커니즘(HTML 및 Javascript 파서)에 의해 구문 분석되기 때문에 발생하므로, 두 번 인코딩되어야 합니다. 이러한 방식으로 공격자는 Reflected XSS에서처럼 피해자와 상호 작용할 필요 없이 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. Stored XSS(또는 Persistent)로 알려진 이런 공격 유형은, 데이터가 취약한 기능에 간접적으로 제공되므로 감지하기 매우 어려울 수 있으며, 여러 사용자에게 영향을 줄 수 있으므로 더 큰 영향을 미칠 수도 있습니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.username)를 읽고 사용자에게 표시합니다.
<script>
document.write('{!HTMLENCODE($CurrentPage.parameters.username)}')
</script>
username에 메타 문자 또는 소스 코드가 포함되어 있으면 웹 브라우저에 의해 실행됩니다. 또한 이 예제에서 변수가 JavaScript 파서에 의해 처리되므로 HTMLENCODE의 사용은 XSS 공격을 방지하기에 충분하지 않습니다.Example 1에서처럼 데이터베이스 또는 다른 데이터 저장소는 동적 콘텐트에 포함될 위험한 데이터를 응용 프로그램에 제공할 수 있습니다. 공격자의 관점에서 악성 콘텐트를 저장할 최적의 장소는 모든 사용자 특히 높은 권한을 가진 사용자(민감한 정보를 처리하고 중요한 작업을 수행할 가능성이 높은 사용자)가 액세스할 수 있는 장소입니다.Example 2에서처럼 데이터를 HTTP 요청에서 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. Reflected XSS는 공격자가 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공한 후 사용자에게 다시 적용하여 사용자의 브라우저에 의해 실행될 때 발생합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 공개적으로 게시되거나 피해자에게 직접 전자 메일로 전송되는 URL의 매개 변수로 악성 콘텐트를 포함하는 것입니다. 이러한 방식으로 생성된 URL은 공격자가 피해자를 속여 해당 URL을 방문하게 하는 많은 피싱 기법의 근간을 이룹니다. 사이트가 콘텐트를 사용자에게 다시 적용한 후, 해당 콘텐트가 실행되고 민감한 개인 정보 전달, 피해자 컴퓨터에서 권한이 없는 작업 실행 등과 같은 여러 작업을 수행할 수 있습니다.
<script runat="server">
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
...
</script>
Login 및 EmployeeID는 다음과 같이 정의된 폼 컨트롤입니다.예제 2: 다음 ASP.NET 코드 세그먼트는 프로그래밍 방식이긴 해도
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 1과 동일한 기능을 구현합니다.
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Server.HtmlEncode(Login.Text);
Login에 표준 영숫자 텍스트만 있으면 올바르게 동작합니다. Login가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = Server.HtmlEncode(name);
</script>
EmployeeName은 다음과 같이 정의된 폼 컨트롤입니다.예제 4: 마찬가지로 다음 ASP.NET 코드 세그먼트는
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3과 기능적으로 동일하지만 프로그래밍 방식으로 모든 form elements를 구현합니다.
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = Server.HtmlEncode(name);
Example 1 및 Example 2에서처럼 이러한 코드 세그먼트는 name의 값이 올바르게 동작할 때는 정확하게 수행하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무런 조치도 취하지 않습니다. 이러한 코드 예제는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1 및 Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 3 및 Example 4에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.text 매개 변수를 읽어들이고 HTML 인코딩하여 이를 스크립트 태그 사이의 경고 상자에 표시합니다.
"<script>alert('<CFOUTPUT>HTMLCodeFormat(#Form.text#)</CFOUTPUT>')</script>";
text에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. text에 작은 따옴표, 둥근 괄호 및 세미콜론이 있는 경우, 코드가 실행되는 이후로 alert 텍스트 상자를 종료합니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.user를 읽어 사용자에게 표시합니다.
func someHandler(w http.ResponseWriter, r *http.Request){
r.parseForm()
user := r.FormValue("user")
...
fmt.Fprintln(w, "Username is: ", html.EscapeString(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: ", html.EscapeString(name))
}
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서 볼 수 있듯이 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 반영합니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서 볼 수 있듯이 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.escapeXml="true" 속성(기본 동작)과 함께 <c:out/> 태그와 같은 특정 인코딩 구성을 사용하면 일부 공격은 막을 수 있지만 모든 Cross-Site Scripting 공격은 막을 수 없습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 구성을 사용하는 것은 약한 거부 목록을 사용하여 Cross-Site Scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Static Code Analyzer는 인코딩이 적용되는 경우에도 Cross-Site Scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.eid를 읽어 <c:out/> 태그를 통해 사용자에게 표시합니다.
Employee ID: <c:out value="${param.eid}"/>
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.<c:out/> 태그를 통해 해당 직원의 이름을 인쇄합니다.
<%...
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: <c:out value="${name}"/>
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(URLEncoder.encode(url));
...
url 값이 javascript:로 시작하면 그 뒤에 오는 JavaScript 코드가 WebView 내에 있는 웹 페이지의 컨텍스트에서 실행됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 3과 같이 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.eid를 읽고 이스케이프 처리하여 사용자에게 표시합니다.
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(escape(document.URL.substring(pos,document.URL.length)));
</SCRIPT>
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.escapeXml="true" 속성(기본 동작)과 함께 <c:out/> 태그와 같은 특정 인코딩 구성을 사용하면 일부 공격은 막을 수 있지만 모든 Cross-Site Scripting 공격은 막을 수 없습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 ' 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 구성을 사용하는 것은 약한 거부 목록을 사용하여 Cross-Site Scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Static Code Analyzer는 인코딩이 적용되는 경우에도 Cross-Site Scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(URLEncoder.encode(url))
...
url 값이 javascript:로 시작하면 그 뒤에 오는 JavaScript 코드가 WebView 내에 있는 웹 페이지의 컨텍스트에서 실행됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 3과 같이 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.myapp://input_to_the_application). 그런 다음 URL의 신뢰할 수 없는 데이터가 UIWebView 구성 요소의 HTML 출력을 렌더링하는 데 사용됩니다.
...
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
...
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
NSString *htmlPage = [NSString stringWithFormat: @"%@/%@/%@", @"...<input type=text onclick=\"callFunction('",
[DefaultEncoder encodeForHTML:partAfterSlashSlash],
@"')\" />"];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:htmlPage baseURL:nil];
...
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 데이터베이스에서 읽어들이고 HTML로 인코딩하기 때문에 덜 위험한 것처럼 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 공격자가 제공하는 익스플로이트는 인코딩한 문자를 무시하거나 HTML 인코딩의 영향을 받지 않는 컨텍스트에 입력할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터는 사용자 지정 URL 스키마에서 직접 읽어 들여 UIWebView 응답의 콘텐트에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 iOS 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 사용자 지정 스키마 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 취약한 응용 프로그램을 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 앱이 공격자의 컨텐츠를 사용자에게 보내면, 컨텐츠가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.htmlspecialchars() 또는 htmlentities()와 같은 특정 인코딩 함수를 사용하면 일부 cross-site scripting 공격만 방지할 수 있습니다. 데이터가 나타나는 컨텍스트에 따라 HTML로 인코딩된 기본 <, >, & 및 " 외의 문자와 XML로 인코딩된 <, >, &, " 및 '(ENT_QUOTES가 설정된 경우에만) 외의 문자는 메타 의미를 지닐 수 있습니다. 그러한 인코딩 함수를 사용하는 것은 약한 거부 목록을 사용하여 cross-site scripting을 막는 것과 동일하며 공격자가 브라우저에서 실행될 악의적인 코드를 삽입할 수 있습니다. 데이터가 정적으로 나타나는 컨텍스트를 정확하게 식별하는 것이 항상 가능하지는 않기 때문에 Fortify Secure Coding Rulepacks는 인코딩이 적용되는 경우에도 cross-site scripting 검사 결과를 보고하고 해당 결과를 Cross-Site Scripting: Poor Validation 이슈로 표시합니다.text 매개 변수를 읽어들이고 HTML 인코딩하여 이를 스크립트 태그 사이의 경고 상자에 표시합니다.
<?php
$var=$_GET['text'];
...
$var2=htmlspecialchars($var);
echo "<script>alert('$var2')</script>";
?>
text에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. text에 작은 따옴표, 둥근 괄호 및 세미콜론이 있는 경우, 코드가 실행되는 이후로 alert 텍스트 상자를 종료합니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.eid를 읽고 URL 인코딩하여 사용자에게 표시합니다.
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || HTMLDB_UTIL.url_encode(eid) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || HTMLDB_UTIL.url_encode(name) || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.eid를 읽고 HTML 인코딩하여 사용자에게 표시합니다.
req = self.request() # fetch the request object
eid = req.field('eid',None) # tainted request message
...
self.writeln("Employee ID:" + escape(eid))
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
...
cursor.execute("select * from emp where id="+eid)
row = cursor.fetchone()
self.writeln('Employee name: ' + escape(row["emp"]))
...
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.eid를 읽고 HTML 인코딩하여 사용자에게 표시합니다.
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.Rack::Request#params()를 Example 1에서처럼 사용하는 경우에는 GET 매개 변수와 POST 매개 변수가 모두 있으므로 URL에 악의적인 코드가 추가되는 것 외에도 다양한 유형의 공격에 취약해질 수 있습니다.
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.eid를 읽어 사용자에게 표시합니다.
def getEmployee = Action { implicit request =>
var eid = request.getQueryString("eid")
eid = StringEscapeUtils.escapeHtml(eid); // insufficient validation
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.myapp://input_to_the_application). 그런 다음 URL의 신뢰할 수 없는 데이터가 UIWebView 구성 요소의 HTML 출력을 렌더링하는 데 사용됩니다.
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
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
}
...
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 데이터베이스에서 읽어들이고 HTML로 인코딩하기 때문에 덜 위험한 것처럼 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 공격자가 제공하는 익스플로이트는 인코딩한 문자를 무시하거나 HTML 인코딩의 영향을 받지 않는 컨텍스트에 입력할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 내의 텍스트에 표준 영숫자 텍스트만 있으면 문제없이 작동합니다. inputTextField 내의 텍스트에 메타 문자나 소스 코드가 포함되어 있으면 웹 브라우저에서 HTTP 응답을 표시할 때 입력을 코드로 실행할 수 있습니다.Example 1에서처럼 데이터는 사용자 지정 URL 스키마에서 직접 읽어 들여 UIWebView 응답의 콘텐트에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 iOS 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 사용자 지정 스키마 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 취약한 응용 프로그램을 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 앱이 공격자의 컨텐츠를 사용자에게 보내면, 컨텐츠가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 3에서는 대상 응용 프로그램 외부의 소스에서 대상 응용 프로그램의 사용자 지정 URL 스키마를 사용하여 URL 요청을 생성하고, 이어서 URL 요청의 확인되지 않은 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 다시 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.eid를 읽고 HTML 인코딩하여 사용자에게 표시합니다.
...
eid = Request("eid")
Response.Write "Employee ID:" & Server.HTMLEncode(eid) & "<br/>"
..
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & Server.HTMLEncode(objADORecordSet("name"))
objADORecordSet.MoveNext
Wend
...
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.eid를 읽어 사용자에게 표시합니다.
...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
...
DATA: BEGIN OF itab_employees,
eid TYPE employees-itm,
name TYPE employees-name,
END OF itab_employees,
itab LIKE TABLE OF itab_employees.
...
itab_employees-eid = '...'.
APPEND itab_employees TO itab.
SELECT *
FROM employees
INTO CORRESPONDING FIELDS OF TABLE itab_employees
FOR ALL ENTRIES IN itab
WHERE eid = itab-eid.
ENDSELECT.
...
response->append_cdata( 'Employee Name: ').
response->append_cdata( itab_employees-name ).
...
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.eid를 읽어 사용자에게 표시합니다.
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var eid:String = String(params["eid"]);
...
var display:TextField = new TextField();
display.htmlText = "Employee ID: " + eid;
...
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
stmt.sqlConnection = conn;
stmt.text = "select * from emp where id="+eid;
stmt.execute();
var rs:SQLResult = stmt.getResult();
if (null != rs) {
var name:String = String(rs.data[0]);
var display:TextField = new TextField();
display.htmlText = "Employee Name: " + name;
}
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.username)를 읽고 사용자에게 표시합니다.
<script>
document.write('{!$CurrentPage.parameters.username}')
</script>
username에 메타 문자 또는 소스 코드가 포함되어 있으면 웹 브라우저에 의해 실행됩니다.
...
variable = Database.query('SELECT Name FROM Contact WHERE id = ID');
...
<div onclick="this.innerHTML='Hello {!variable}'">Click me!</div>
Example 1에서처럼 이 코드는 name의 값이 제대로 정의된 경우(예: 영숫자)에 올바르게 작동하지만, 악성 데이터를 확인하기 위한 작업은 수행하지 않습니다. 데이터베이스에서 읽는 경우에도, 데이터베이스의 콘텐트가 사용자가 제공하는 데이터에서 제공될 수 있기 때문에 값을 적절하게 확인해야 합니다. 이러한 방식으로 공격자는 Reflected XSS에서처럼 피해자와 상호 작용할 필요 없이 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. Stored XSS(또는 Persistent)로 알려진 이런 공격 유형은, 데이터가 취약한 기능에 간접적으로 제공되므로 감지하기 매우 어려울 수 있으며, 여러 사용자에게 영향을 줄 수 있으므로 더 큰 영향을 미칠 수도 있습니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. Reflected XSS는 공격자가 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공한 후 사용자에게 다시 적용하여 사용자의 브라우저에 의해 실행될 때 발생합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 공개적으로 게시되거나 피해자에게 직접 전자 메일로 전송되는 URL의 매개 변수로 악성 콘텐트를 포함하는 것입니다. 이러한 방식으로 생성된 URL은 공격자가 피해자를 속여 해당 URL을 방문하게 하는 많은 피싱 기법의 근간을 이룹니다. 사이트가 콘텐트를 사용자에게 다시 적용한 후, 해당 콘텐트가 실행되고 민감한 개인 정보 전달, 피해자 컴퓨터에서 권한이 없는 작업 실행 등과 같은 여러 작업을 수행할 수 있습니다.Example 2에서처럼 데이터베이스 또는 다른 데이터 저장소는 동적 콘텐트에 포함될 위험한 데이터를 응용 프로그램에 제공할 수 있습니다. 공격자의 관점에서 악성 콘텐트를 저장할 최적의 장소는 모든 사용자 특히 높은 권한을 가진 사용자(민감한 정보를 처리하고 중요한 작업을 수행할 가능성이 높은 사용자)가 액세스할 수 있는 장소입니다.
<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>
Login 및 EmployeeID는 다음과 같이 정의된 폼 컨트롤입니다.예제 2: 다음 ASP.NET 코드 세그먼트는
<form runat="server">
<asp:TextBox runat="server" id="Login"/>
...
<asp:Label runat="server" id="EmployeeID"/>
</form>
Example 1을 구현하는 프로그래밍 방식을 보여 줍니다.
protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;
Login에 표준 영숫자 텍스트만 있으면 올바르게 동작합니다. Login가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
<script runat="server">
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
</script>
EmployeeName은 다음과 같이 정의된 폼 컨트롤입니다.예제 4: 다음 ASP.NET 코드 세그먼트는
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server">
...
</form>
Example 3과 기능적으로 동일하지만 프로그래밍 방식으로 모든 form elements를 구현합니다.
protected System.Web.UI.WebControls.Label EmployeeName;
...
string query = "select * from emp where id=" + eid;
sda = new SqlDataAdapter(query, conn);
DataTable dt = new DataTable();
sda.Fill(dt);
string name = dt.Rows[0]["Name"];
...
EmployeeName.Text = name;
Example 1 및 Example 2에서처럼 이러한 코드 예제는 name의 값이 올바르게 동작할 때는 정확하게 작동하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무런 조치도 취하지 않습니다. 이러한 코드 예제는 name의 값을 응용 프로그램이 콘텐트를 분명하게 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1 및 Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 3 및 Example 4에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.EID를 읽어 사용자에게 표시합니다.
...
EXEC CICS
WEB READ
FORMFIELD(ID)
VALUE(EID)
...
END-EXEC.
EXEC CICS
WEB SEND
FROM(EID)
...
END-EXEC.
...
EID에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. EID가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
...
EXEC SQL
SELECT NAME
INTO :ENAME
FROM EMPLOYEE
WHERE ID = :EID
END-EXEC.
EXEC CICS
WEB SEND
FROM(ENAME)
...
END-EXEC.
...
Example 1에서처럼 이 코드는 ENAME의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 ENAME의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 ENAME의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Stored XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTML 폼에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. 공격자가 다음을 수행하는 경우 저장된 XSS 악용 발생 eid를 읽어 사용자에게 표시합니다.
<cfoutput>
Employee ID: #Form.eid#
</cfoutput>
Form.eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. Form.eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
<cfquery name="matchingEmployees" datasource="cfsnippets">
SELECT name
FROM Employees
WHERE eid = '#Form.eid#'
</cfquery>
<cfoutput>
Employee Name: #name#
</cfoutput>
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.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(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서 볼 수 있듯이 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 반영합니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서 볼 수 있듯이 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.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 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.
...
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 내에 있는 웹 페이지의 컨텍스트에서 실행됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 3과 같이 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.eid를 읽고 사용자에게 표시합니다.
var http = require('http');
var url = require('url');
...
function listener(request, response){
var eid = url.parse(request.url, true)['query']['eid'];
if (eid !== undefined){
response.write('<p>Welcome, ' + eid + '!</p>');
}
...
}
...
http.createServer(listener).listen(8080);
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
var http = require('http');
...
function listener(request, response){
connection.query('SELECT * FROM emp WHERE eid="' + eid + '"', function(err, rows){
if (!err && rows.length > 0){
response.write('<p>Welcome, ' + rows[0].name + '!</p>');
}
...
});
...
}
...
http.createServer(listener).listen(8080);
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.eid를 읽은 다음 서블릿의 응답에서 사용자에게 값을 되돌려 주어 표시합니다.
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 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.
...
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 내에 있는 웹 페이지의 컨텍스트에서 실행됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Example 3과 같이 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.myapp://input_to_the_application). 그런 다음 URL의 신뢰할 수 없는 데이터가 UIWebView 구성 요소의 HTML 출력을 렌더링하는 데 사용됩니다.
- (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url {
UIWebView *webView;
NSString *partAfterSlashSlash = [[url host] stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
webView = [[UIWebView alloc] initWithFrame:CGRectMake(0.0,0.0,360.0, 480.0)];
[webView loadHTMLString:partAfterSlashSlash baseURL:nil]
...
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터는 사용자 지정 URL 스키마에서 직접 읽어 들여 UIWebView 응답의 콘텐트에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 iOS 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 사용자 지정 스키마 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 취약한 응용 프로그램을 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 앱이 공격자의 컨텐츠를 사용자에게 보내면, 컨텐츠가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.eid를 읽어 사용자에게 표시합니다.
<?php
$eid = $_GET['eid'];
...
?>
...
<?php
echo "Employee ID: $eid";
?>
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
<?php...
$con = mysql_connect($server,$user,$password);
...
$result = mysql_query("select * from emp where id="+eid);
$row = mysql_fetch_array($result)
echo 'Employee name: ', mysql_result($row,0,'name');
...
?>
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.eid를 읽어 사용자에게 표시합니다.
...
-- Assume QUERY_STRING looks like EID=EmployeeID
eid := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 5);
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee ID: ' || eid || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
...
SELECT ename INTO name FROM emp WHERE id = eid;
HTP.htmlOpen;
HTP.headOpen;
HTP.title ('Employee Information');
HTP.headClose;
HTP.bodyOpen;
HTP.br;
HTP.print('Employee Name: ' || name || '');
HTP.br;
HTP.bodyClose;
HTP.htmlClose;
...
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.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(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.eid를 읽어 사용자에게 표시합니다.
eid = req.params['eid'] #gets request parameter 'eid'
Rack::Response.new.finish do |res|
...
res.write("Employee ID: #{eid}")
end
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.Rack::Request#params()를 Example 1에서처럼 사용하는 경우에는 GET 매개 변수와 POST 매개 변수가 모두 있으므로 URL에 악의적인 코드가 추가되는 것 외에도 다양한 유형의 공격에 취약해질 수 있습니다.
...
rs = conn.exec_params("select * from emp where id=?", eid)
...
Rack::Response.new.finish do |res|
...
rs.each do |row|
res.write("Employee name: #{escape(row['name'])}")
...
end
end
...
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.eid를 읽어 사용자에게 표시합니다.
def getEmployee = Action { implicit request =>
val eid = request.getQueryString("eid")
val employee = getEmployee(eid)
if (employee == Null) {
val html = Html(s"Employee ID ${eid} not found")
Ok(html) as HTML
}
...
}
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 내의 텍스트에 표준 영숫자 텍스트만 있으면 문제없이 작동합니다. inputTextField 내의 텍스트에 메타 문자나 소스 코드가 포함되어 있으면 웹 브라우저에서 HTTP 응답을 표시할 때 입력을 코드로 실행할 수 있습니다.myapp://input_to_the_application). 그런 다음 URL의 신뢰할 수 없는 데이터가 UIWebView 구성 요소의 HTML 출력을 렌더링하는 데 사용됩니다.
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = UIWebView()
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
}
Example 2에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서는 데이터를 사용자가 제어할 수 있는 UI 구성 요소에서 직접 읽어 들여 HTTP 응답에 다시 적용합니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서는 대상 응용 프로그램 외부의 소스에서 대상 응용 프로그램의 사용자 지정 URL 스키마를 사용하여 URL 요청을 생성하고, 이어서 URL 요청의 확인되지 않은 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 다시 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.Example 3에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.eid를 읽어 사용자에게 표시합니다.
...
eid = Request("eid")
Response.Write "Employee ID:" & eid & "<br/>"
..
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
...
eid = Request("eid")
strSQL = "Select * from emp where id=" & eid
objADORecordSet.Open strSQL, strConnect, adOpenDynamic, adLockOptimistic, adCmdText
while not objRec.EOF
Response.Write "Employee Name:" & objADORecordSet("name")
objADORecordSet.MoveNext
Wend
...
Example 1에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.apex:iframe 소스 URL로 수락하면 Visualforce 페이지 내에서 악성 콘텐트가 로드될 수 있습니다.iframe URL로 사용됩니다.Salesforce.com, 피해자는 해당 페이지를 신뢰하고 요청된 모든 정보를 제공합니다.iframesrc URL 매개 변수는 apex:iframe 대상 URL로 직접 사용됩니다.
<apex:page>
<apex:iframe src="{!$CurrentPage.parameters.iframesrc}"></apex:iframe>
</apex:page>
iframesrc 매개 변수를 제공하는 경우, 프레임은 악성 웹 사이트의 콘텐트로 렌더링됩니다.
<iframe src="http://evildomain.com/">
author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 Cookie Manipulation 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.
@HttpGet
global static void doGet() {
...
Map<String, String> params = ApexPages.currentPage().getParameters();
RestResponse res = RestContext.response;
res.addHeader(params.get('name'), params.get('value'));
...
}
author 및 Jane Smith로 구성되어 있다고 가정할 때 이 헤더를 포함하는 HTTP 응답은 다음과 같은 형식일 수 있습니다.
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo 및 bar와 같은 악성 이름/값 쌍을 전송할 수 있습니다. 그러면 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
HttpResponse.AddHeader() 메서드로 보낼 때 %0d, %0a 및 %00으로 변환합니다. 새 줄 문자로 헤더를 설정하지 못하도록 방지하는 최신 .NET 프레임워크를 사용한다면, 응용 프로그램은 HTTP Response Splitting에 취약하지 않을 수도 있습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
Author.Text에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
...
EXEC CICS
WEB READ
FORMFIELD(NAME)
VALUE(AUTHOR)
...
END-EXEC.
EXEC CICS
WEB WRITE
HTTPHEADER(COOKIE)
VALUE(AUTHOR)
...
END-EXEC.
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1/1 200 OK
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 Cookie Manipulation 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.
final server = await HttpServer.bind('localhost', 18081);
server.listen((request) async {
final headers = request.headers;
final contentType = headers.value('content-type');
final client = HttpClient();
final clientRequest = await client.getUrl(Uri.parse('https://example.com'));
clientRequest.headers.add('Content-Type', contentType as Object);
});
author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.name 및 value가 공격자에 의해 제어될 수 있다고 가정합니다. 코드는 이름 및 값이 공격자에 의해 제어될 수 있는 HTTP 헤더를 설정합니다.
...
NSURLSessionConfiguration * config = [[NSURLSessionConfiguration alloc] init];
NSMutableDictionary *dict = @{};
[dict setObject:value forKey:name];
[config setHTTPAdditionalHeaders:dict];
...
author 및 Jane Smith로 구성되었다고 가정하면 이 헤더가 포함된 HTTP 응답의 형식은 다음과 같을 수 있습니다.
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo 및 bar와 같은 악의적인 이름/값 쌍을 제출할 수 있고 그러면 HTTP 응답이 다음 형식의 두 응답으로 분할됩니다.
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
header() 함수에 전달될 때 경고를 생성하고 헤더 생성을 중단합니다. 사용 중인 PHP 버전이 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.
<?php
$location = $_GET['some_location'];
...
header("location: $location");
?>
HTTP/1.1 200 OK
...
location: index.html
...
some_location에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "index.html\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
...
-- Assume QUERY_STRING looks like AUTHOR_PARAM=Name
author := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 14);
OWA_UTIL.mime_header('text/html', false);
OWA_COOKE.send('author', author);
OWA_UTIL.http_header_close;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
location = req.field('some_location')
...
response.addHeader("location",location)
HTTP/1.1 200 OK
...
location: index.html
...
some_location에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "index.html\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.author를 읽어들여 사이트의 다른 부분에 대한 get 요청에 사용합니다.
author = req.params[AUTHOR_PARAM]
http = Net::HTTP.new(URI("http://www.mysite.com"))
http.post('/index.php', "author=#{author}")
POST /index.php HTTP/1.1
Host: www.mysite.com
author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nPOST /index.php HTTP/1.1\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
POST /index.php HTTP/1.1
Host: www.mysite.com
author=Wiley Hacker
POST /index.php HTTP/1.1
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.name 및 value가 공격자에 의해 제어될 수 있다고 가정합니다. 코드는 이름 및 값이 공격자에 의해 제어될 수 있는 HTTP 헤더를 설정합니다.
...
var headers = []
headers[name] = value
let config = NSURLSessionConfiguration.backgroundSessionConfigurationWithIdentifier("com.acme")
config.HTTPAdditionalHeaders = headers
...
author 및 Jane Smith로 구성되었다고 가정하면 이 헤더가 포함된 HTTP 응답의 형식은 다음과 같을 수 있습니다.
HTTP/1.1 200 OK
...
author:Jane Smith
...
HTTP/1.1 200 OK\r\n...foo 및 bar와 같은 악의적인 이름/값 쌍을 제출할 수 있고 그러면 HTTP 응답이 다음 형식의 두 응답으로 분할됩니다.
HTTP/1.1 200 OK
...
HTTP/1.1 200 OK
...
foo:bar
author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 Cookie Manipulation 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
...
Cookie cookie = new Cookie('author', author, '/', -1, false);
ApexPages.currentPage().setCookies(new Cookie[] {cookie});
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
author에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."와 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
<cfcookie name = "author"
value = "#Form.author#"
expires = "NOW">
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 Cookie Manipulation 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
...
author := request.FormValue("AUTHOR_PARAM")
cookie := http.Cookie{
Name: "author",
Value: author,
Domain: "www.example.com",
}
http.SetCookie(w, &cookie)
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."와 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
cookie.setMaxAge(cookieExpiration);
response.addCookie(cookie);
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
Example 1을 Android 플랫폼에 맞게 조정합니다.교차 사용자 변조(cross-user defacement): 공격자는 피해 서버에 하나의 요청을 보낼 수 있게 되어 서버가 두 개의 응답을 만들게 하는데 두 번째 응답은 다른 요청에 대한 응답으로 잘못 해석될 수 있습니다. 이를테면, 서버와 같은 TCP 연결을 공유하는 다른 사용자의 요청에 대한 응답으로 해석됩니다. 이는 사용자를 속여 악성 요청을 사용자 스스로 전송하게 하거나 공유 프록시 서버처럼 공격자와 사용자가 서버에 대한 하나의 TCP 연결을 공유하는 경우 원격으로 전송하도록 합니다. 공격자가 이 능력을 이용하여 사용자가 응용 프로그램이 해킹당했다고 믿게 만들고 응용 프로그램 보안에 대한 자신감을 상실하게 만드는 정도면 다행이라고 할 수 있습니다. 최악의 경우, 공격자는 응용 프로그램 동작을 모방하여 계정 번호와 암호 등의 개인 정보를 공격자에게 리디렉션하는 특별히 제작된 콘텐트를 이용하기도 합니다.
...
CookieManager webCookieManager = CookieManager.getInstance();
String author = this.getIntent().getExtras().getString(AUTHOR_PARAM);
String setCookie = "author=" + author + "; max-age=" + cookieExpiration;
webCookieManager.setCookie(url, setCookie);
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
author = form.author.value;
...
document.cookie = "author=" + author + ";expires="+cookieExpiration;
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
<?php
$author = $_GET['AUTHOR_PARAM'];
...
header("author: $author");
?>
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
location = req.field('some_location')
...
response.addHeader("location",location)
HTTP/1.1 200 OK
...
location: index.html
...
some_location에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "index.html\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
location: index.html
HTTP/1.1 200 OK
...
IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 Cookie Manipulation 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.IllegalArgumentException을 발생시킵니다. 응용 프로그램 서버가 새 줄 문자로 헤더를 설정하는 것을 방해한다면, 해당 응용 프로그램은 HTTP Response Splitting에 취약하지 않습니다. 그러나, 단지 새 줄 문자에 대한 필터링은 쿠키 조작 또는 Open Redirection에 대해 응용 프로그램을 취약하게 남겨둘 수 있기 때문에 사용자 입력으로 HTTP 헤더를 설정할 때는 여전히 주의해야 합니다.author를 읽어들여 HTTP 응답의 쿠키 헤더에 설정합니다.
...
author = Request.Form(AUTHOR_PARAM)
Response.Cookies("author") = author
Response.Cookies("author").Expires = cookieExpiration
...
HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...
AUTHOR_PARAM에 전송된 값에 CR 및 LF 문자가 들어 있지 않을 때에만 이 형식을 유지합니다. 공격자가 "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n..."과 같은 악성 문자열을 전송하는 경우 HTTP 응답은 다음과 같이 두 개의 응답으로 나누어집니다.
HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker
HTTP/1.1 200 OK
...
...
HttpRequest req = new HttpRequest();
req.setEndpoint('http://example.com');
HTTPResponse res = new Http().send(req);
...
HttpResponse 개체인 res는 암호화 및 인증되지 않는 채널을 통해 제공되기 때문에 침해가 발생할 수 있습니다.
var account = new CloudStorageAccount(storageCredentials, false);
...
String url = 'http://10.0.2.2:11005/v1/key';
Response response = await get(url, headers: headers);
...
response는 암호화 및 인증되지 않는 채널을 통해 제공되기 때문에 침해가 발생할 수 있습니다.
helloHandler := func(w http.ResponseWriter, req *http.Request) {
io.WriteString(w, "Hello, world!\n")
}
http.HandleFunc("/hello", helloHandler)
log.Fatal(http.ListenAndServe(":8080", nil))
URL url = new URL("http://www.android.com/");
HttpURLConnection urlConnection = (HttpURLConnection) url.openConnection();
try {
InputStream in = new BufferedInputStream(urlConnection.getInputStream());
readStream(in);
...
}
instream은 암호화 및 인증되지 않는 채널을 통해 제공되기 때문에 침해가 발생할 수 있습니다.
var http = require('http');
...
http.request(options, function(res){
...
});
...
http.IncomingMessage 개체인 res는 암호화 및 인증되지 않는 채널을 통해 제공되기 때문에 침해가 발생할 수 있습니다.
NSString * const USER_URL = @"http://localhost:8080/igoat/user";
NSMutableURLRequest *request = [NSMutableURLRequest requestWithURL:[NSURL URLWithString:USER_URL]];
[[NSURLConnection alloc] initWithRequest:request delegate:self];
...
stream_socket_enable_crypto($fp, false);
...
require 'net/http'
conn = Net::HTTP.new(URI("http://www.website.com/"))
in = conn.get('/index.html')
...
in은 암호화 및 인증되지 않는 채널을 통해 제공되기 때문에 침해가 발생할 수 있습니다.
val url = Uri.from(scheme = "http", host = "192.0.2.16", port = 80, path = "/")
val responseFuture: Future[HttpResponse] = Http().singleRequest(HttpRequest(uri = url))
responseFuture는 암호화 및 인증되지 않는 채널을 통해 제공되기 때문에 침해가 발생할 수 있습니다.
let USER_URL = "http://localhost:8080/igoat/user"
let request : NSMutableURLRequest = NSMutableURLRequest(URL:NSURL(string:USER_URL))
let conn : NSURLConnection = NSURLConnection(request:request, delegate:self)
...
encryptionKey = "lakdsljkalkjlksdfkl".
...
...
var encryptionKey:String = "lakdsljkalkjlksdfkl";
var key:ByteArray = Hex.toArray(Hex.fromString(encryptionKey));
...
var aes.ICipher = Crypto.getCipher("aes-cbc", key, padding);
...
...
Blob encKey = Blob.valueOf('YELLOW_SUBMARINE');
Blob encrypted = Crypto.encrypt('AES128', encKey, iv, input);
...
...
using (SymmetricAlgorithm algorithm = SymmetricAlgorithm.Create("AES"))
{
string encryptionKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = Encoding.ASCII.GetBytes(encryptionKey);
algorithm.Key = keyBytes;
...
}
...
char encryptionKey[] = "lakdsljkalkjlksdfkl";
...
...
<cfset encryptionKey = "lakdsljkalkjlksdfkl" />
<cfset encryptedMsg = encrypt(msg, encryptionKey, 'AES', 'Hex') />
...
...
key := []byte("lakdsljkalkjlksd");
block, err := aes.NewCipher(key)
...
...
private static final String encryptionKey = "lakdsljkalkjlksdfkl";
byte[] keyBytes = encryptionKey.getBytes();
SecretKeySpec key = new SecretKeySpec(keyBytes, "AES");
Cipher encryptCipher = Cipher.getInstance("AES");
encryptCipher.init(Cipher.ENCRYPT_MODE, key);
...
...
var crypto = require('crypto');
var encryptionKey = "lakdsljkalkjlksdfkl";
var algorithm = 'aes-256-ctr';
var cipher = crypto.createCipher(algorithm, encryptionKey);
...
...
{
"username":"scott"
"password":"tiger"
}
...
...
NSString encryptionKey = "lakdsljkalkjlksdfkl";
...
...
$encryption_key = 'hardcoded_encryption_key';
//$filter = new Zend_Filter_Encrypt('hardcoded_encryption_key');
$filter = new Zend_Filter_Encrypt($encryption_key);
$filter->setVector('myIV');
$encrypted = $filter->filter('text_to_be_encrypted');
print $encrypted;
...
...
from Crypto.Ciphers import AES
encryption_key = b'_hardcoded__key_'
cipher = AES.new(encryption_key, AES.MODE_CFB, iv)
msg = iv + cipher.encrypt(b'Attack at dawn')
...
_hardcoded__key_를 변경할 수 있습니다. 비양심적인 직원이 이 정보에 대한 접근 권한을 갖게 되면 이를 사용하여 시스템에서 암호화된 데이터에 침입할 수 있습니다.
require 'openssl'
...
encryption_key = 'hardcoded_encryption_key'
...
cipher = OpenSSL::Cipher::AES.new(256, 'GCM')
cipher.encrypt
...
cipher.key=encryption_key
...
예제 2: 다음 코드는 하드코드된 암호화 키를 사용하여 AES 암호화를 수행합니다.
...
let encryptionKey = "YELLOW_SUBMARINE"
...
...
CCCrypt(UInt32(kCCEncrypt),
UInt32(kCCAlgorithmAES128),
UInt32(kCCOptionPKCS7Padding),
"YELLOW_SUBMARINE",
16,
iv,
plaintext,
plaintext.length,
ciphertext.mutableBytes,
ciphertext.length,
&numBytesEncrypted)
...
...
-----BEGIN RSA PRIVATE KEY-----
MIICXwIBAAKBgQCtVacMo+w+TFOm0p8MlBWvwXtVRpF28V+o0RNPx5x/1TJTlKEl
...
DiJPJY2LNBQ7jS685mb6650JdvH8uQl6oeJ/aUmq63o2zOw=
-----END RSA PRIVATE KEY-----
...
...
Dim encryptionKey As String
Set encryptionKey = "lakdsljkalkjlksdfkl"
Dim AES As New System.Security.Cryptography.RijndaelManaged
On Error GoTo ErrorHandler
AES.Key = System.Text.Encoding.ASCII.GetBytes(encryptionKey)
...
Exit Sub
...
...
production:
secret_key_base: 0ab25e26286c4fb9f7335947994d83f19861354f19702b7bbb84e85310b287ba3cdc348f1f19c8cdc08a7c6c5ad2c20ad31ecda177d2c74aa2d48ec4a346c40e
...
@HttpGet
global static void doGet() {
RestRequest req = RestContext.request;
String val = req.params.get('val');
try {
Integer i = Integer.valueOf(val);
...
} catch (TypeException e) {
System.Debug(LoggingLevel.INFO, 'Failed to parse val: '+val);
}
}
val에 문자열 "twenty-one"을 전송하면 다음 항목이 기록됩니다.
Failed to parse val: twenty-one
twenty-one%0a%0aUser+logged+out%3dbadguy" 문자열을 다음 항목이 기록됩니다.
Failed to parse val: twenty-one
User logged out=badguy
...
String val = request.Params["val"];
try {
int value = Int.Parse(val);
}
catch (FormatException fe) {
log.Info("Failed to parse val = " + val);
}
...
val에 문자열 "twenty-one"을 전송하면 다음 항목이 기록됩니다.
INFO: Failed to parse val=twenty-one
twenty-one%0a%0aINFO:+User+logged+out%3dbadguy" 문자열을 전송하는 경우 다음 항목이 기록됩니다.
INFO: Failed to parse val=twenty-one
INFO: User logged out=badguy
Example 1을 Android 플랫폼에 맞게 조정합니다.
...
String val = this.Intent.Extras.GetString("val");
try {
int value = Int.Parse(val);
}
catch (FormatException fe) {
Log.E(TAG, "Failed to parse val = " + val);
}
...
...
var idValue string
idValue = req.URL.Query().Get("id")
num, err := strconv.Atoi(idValue)
if err != nil {
sysLog.Debug("Failed to parse value: " + idValue)
}
...
val에 문자열 "twenty-one"을 전송하면 다음 항목이 기록됩니다.
INFO: Failed to parse val=twenty-one
twenty-one%0a%0aINFO:+User+logged+out%3dbadguy" 문자열을 전송하는 경우 다음 항목이 기록됩니다.
INFO: Failed to parse val=twenty-one
INFO: User logged out=badguy
...
String val = request.getParameter("val");
try {
int value = Integer.parseInt(val);
}
catch (NumberFormatException nfe) {
log.info("Failed to parse val = " + val);
}
...
val에 문자열 "twenty-one"을 전송하면 다음 항목이 기록됩니다.
INFO: Failed to parse val=twenty-one
twenty-one%0a%0aINFO:+User+logged+out%3dbadguy" 문자열을 전송하는 경우 다음 항목이 기록됩니다.
INFO: Failed to parse val=twenty-one
INFO: User logged out=badguy
Example 1을 Android 플랫폼에 맞게 조정합니다.
...
String val = this.getIntent().getExtras().getString("val");
try {
int value = Integer.parseInt();
}
catch (NumberFormatException nfe) {
Log.e(TAG, "Failed to parse val = " + val);
}
...
var cp = require('child_process');
var http = require('http');
var url = require('url');
function listener(request, response){
var val = url.parse(request.url, true)['query']['val'];
if (isNaN(val)){
console.error("INFO: Failed to parse val = " + val);
}
...
}
...
http.createServer(listener).listen(8080);
...
val에 문자열 "twenty-one"을 전송하면 다음 항목이 기록됩니다.
INFO: Failed to parse val=twenty-one
twenty-one%0a%0aINFO:+User+logged+out%3dbadguy" 문자열을 전송하는 경우 다음 항목이 기록됩니다.
INFO: Failed to parse val=twenty-one
INFO: User logged out=badguy
...
val = request.GET["val"]
try:
int_value = int(val)
except:
logger.debug("Failed to parse val = " + val)
...
val에 문자열 "twenty-one"을 전송하면 다음 항목이 기록됩니다.
INFO: Failed to parse val=twenty-one
twenty-one%0a%0aINFO:+User+logged+out%3dbadguy" 문자열을 전송하는 경우 다음 항목이 기록됩니다.
INFO: Failed to parse val=twenty-one
INFO: User logged out=badguy
...
val = req['val']
unless val.respond_to?(:to_int)
logger.debug("Failed to parse val")
logger.debug(val)
end
...
val에 문자열 "twenty-one"을 전송하면 다음 항목이 기록됩니다.
DEBUG: Failed to parse val
DEBUG: twenty-one
twenty-one%0a%DEBUG:+User+logged+out%3dbadguy" 문자열을 전송하는 경우 다음 항목이 기록됩니다.
DEBUG: Failed to parse val
DEBUG: twenty-one
DEBUG: User logged out=badguy
dest 요청 매개 변수에서 구문 분석한 URL을 열도록 지시합니다.
...
DATA: str_dest TYPE c.
str_dest = request->get_form_field( 'dest' ).
response->redirect( str_dest ).
...
Example 1의 코드가 브라우저를 “http://www.wilyhacker.com”으로 리디렉션합니다.dest 요청 매개 변수에서 읽어들인 URL을 열도록 지시합니다.
...
var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
var strDest:String = String(params["dest"]);
host.updateLocation(strDest);
...
Example 1의 코드가 브라우저를 “http://www.wilyhacker.com”으로 리디렉션합니다.dest 요청 매개 변수의 URL로 구성된 PageReference 개체를 반환합니다.
public PageReference pageAction() {
...
PageReference ref = ApexPages.currentPage();
Map<String,String> params = ref.getParameters();
return new PageReference(params.get('dest'));
}
Example 1의 코드가 브라우저를 "http://www.wilyhacker.com"으로 리디렉션합니다.dest 요청 매개 변수에서 구문 분석한 URL을 열도록 지시합니다.
String redirect = Request["dest"];
Response.Redirect(redirect);
Example 1의 코드가 브라우저를 “http://www.wilyhacker.com”으로 리디렉션합니다.dest 요청 매개 변수에서 구문 분석한 URL을 열도록 지시합니다.
...
final server = await HttpServer.bind(host, port);
await for (HttpRequest request in server) {
final response = request.response;
final headers = request.headers;
final strDest = headers.value('strDest');
response.headers.contentType = ContentType.text;
response.redirect(Uri.parse(strDest!));
await response.close();
}
...
Example 1의 코드가 브라우저를 “http://www.wilyhacker.com”으로 리디렉션합니다.dest 요청 매개 변수에서 구문 분석한 URL을 열도록 지시합니다.
...
strDest := r.Form.Get("dest")
http.Redirect(w, r, strDest, http.StatusSeeOther)
...
Example 1의 코드가 브라우저를 “http://www.wilyhacker.com”으로 리디렉션합니다.dest 요청 매개 변수에서 구문 분석한 URL을 열도록 지시합니다.
<end-state id="redirectView" view="externalRedirect:#{requestParameters.dest}" />
Example 1의 코드가 브라우저를 “http://www.wilyhacker.com”으로 리디렉션합니다.dest 요청 매개 변수에서 읽어 들인 URL을 열도록 지시합니다.
...
strDest = form.dest.value;
window.open(strDest,"myresults");
...
Example 1의 코드가 브라우저를 “http://www.wilyhacker.com”으로 리디렉션합니다.dest 요청 매개 변수에서 구문 분석한 URL을 열도록 사용자 브라우저에 지시합니다.
<%
...
$strDest = $_GET["dest"];
header("Location: " . $strDest);
...
%>
Example 1의 코드가 브라우저를 “http://www.wilyhacker.com”으로 리디렉션합니다.dest 요청 매개 변수에서 구문 분석한 URL을 열도록 지시합니다.
...
-- Assume QUERY_STRING looks like dest=http://www.wilyhacker.com
dest := SUBSTR(OWA_UTIL.get_cgi_env('QUERY_STRING'), 6);
OWA_UTIL.redirect_url('dest');
...
Example 1의 코드가 브라우저를 “http://www.wilyhacker.com”으로 리디렉션합니다.dest 요청 매개 변수에서 구문 분석한 URL을 열도록 지시합니다.
...
strDest = request.field("dest")
redirect(strDest)
...
Example 1의 코드가 브라우저를 “http://www.wilyhacker.com”으로 리디렉션합니다.dest 요청 매개 변수에서 구문 분석한 URL을 열도록 지시합니다.
...
str_dest = req.params['dest']
...
res = Rack::Response.new
...
res.redirect("http://#{dest}")
...
Example 1의 코드가 브라우저를 “http://www.wilyhacker.com”으로 리디렉션합니다.dest 요청 매개 변수에서 구문 분석한 URL을 열도록 지시합니다.
def myAction = Action { implicit request =>
...
request.getQueryString("dest") match {
case Some(location) => Redirect(location)
case None => Ok("No url found!")
}
...
}
Example 1의 코드가 브라우저를 “http://www.wilyhacker.com”으로 리디렉션합니다.requestToLoad가 원래 URL의 "dest" 매개 변수(있는 경우) 및 http:// 스키마를 사용하는 원래 URL을 가리키도록 설정하고, 마지막으로 이 요청을 WKWebView 내에서 로드합니다.
...
let requestToLoad : String
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
if let urlComponents = NSURLComponents(URL: url, resolvingAgainstBaseURL: false) {
if let queryItems = urlComponents.queryItems as? [NSURLQueryItem]{
for queryItem in queryItems {
if queryItem.name == "dest" {
if let value = queryItem.value {
request = NSURLRequest(URL:NSURL(string:value))
requestToLoad = request
break
}
}
}
}
if requestToLoad == nil {
urlComponents.scheme = "http"
requestToLoad = NSURLRequest(URL:urlComponents.URL)
}
}
...
}
...
...
let webView : WKWebView
let appDelegate = UIApplication.sharedApplication().delegate as! AppDelegate
webView.loadRequest(appDelegate.requestToLoad)
...
Example 1의 코드가 요청을 시도하고 WKWebView에서 “http://www.wilyhacker.com”을 로드합니다.dest 요청 매개 변수에서 구문 분석한 URL을 열도록 지시합니다.
...
strDest = Request.Form('dest')
HyperLink.NavigateTo strDest
...
Example 1의 코드가 브라우저를 “http://www.wilyhacker.com”으로 리디렉션합니다.