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)
.example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://secure.example.com/에서 배포된 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정하겠습니다.
HttpCookie cookie = new HttpCookie("sessionID", sessionID);
cookie.Domain = ".example.com";
http://insecure.example.com/에 안전성이 낮은 다른 응용 프로그램이 있으며 여기에 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.insecure.example.com을 사용한 Cookie Poisoning 공격을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다..example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://secure.example.com/에서 배포된 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정하겠습니다.
cookie := http.Cookie{
Name: "sessionID",
Value: getSessionID(),
Domain: ".example.com",
}
...
http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.insecure.example.com를 사용한 "쿠키 감염(Cookie Poisoning) 공격"을 수행하여 Secure.example.com의 쿠키를 덮어쓰는, 지나치게 광범위한 자체 쿠키를 생성할 수 있습니다..example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://secure.example.com/에서 배포된 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정하겠습니다.
Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setDomain(".example.com");
http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.insecure.example.com을 사용한 Cookie Poisoning 공격을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다..example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://secure.example.com/에서 배포된 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정하겠습니다.
cookie_options = {};
cookie_options.domain = '.example.com';
...
res.cookie('important_cookie', info, cookie_options);
http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.insecure.example.com을 사용한 Cookie Poisoning 공격을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다..example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://secure.example.com/에서 배포된 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정하겠습니다.
...
NSDictionary *cookieProperties = [NSDictionary dictionary];
...
[cookieProperties setValue:@".example.com" forKey:NSHTTPCookieDomain];
...
NSHTTPCookie *cookie = [NSHTTPCookie cookieWithProperties:cookieProperties];
...
http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.insecure.example.com을 사용한 Cookie Poisoning 공격을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다..example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://secure.example.com/에서 배포된 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정하겠습니다.
setcookie("mySessionId", getSessionID(), 0, "/", ".example.com", true, true);
http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.insecure.example.com을 사용한 Cookie Poisoning 공격을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다..example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://secure.example.com/에서 배포된 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정하겠습니다.
from django.http.response import HttpResponse
...
def view_method(request):
res = HttpResponse()
res.set_cookie("mySessionId", getSessionID(), domain=".example.com")
return res
...
http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.insecure.example.com를 사용한 "쿠키 감염(Cookie Poisoning) 공격"을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 지나치게 광범위한 자체 쿠키를 생성할 수도 있습니다..example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://secure.example.com/에서 배포된 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정하겠습니다.
Ok(Html(command)).withCookies(Cookie("sessionID", sessionID, domain = Some(".example.com")))
http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.insecure.example.com을 사용한 Cookie Poisoning 공격을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다..example.com"과 같은 기본 도메인 전반에 걸쳐 활성화되도록 설정하기도 합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 쿠키는 흔히 세션 ID와 같은 민감한 정보를 전달하기 때문에 응용 프로그램 전반에서 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://secure.example.com/에서 배포된 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 ID 쿠키를 설정한다고 가정하겠습니다.
...
let properties = [
NSHTTPCookieDomain: ".example.com",
NSHTTPCookiePath: "/service",
NSHTTPCookieName: "foo",
NSHTTPCookieValue: "bar",
NSHTTPCookieSecure: true
]
let cookie : NSHTTPCookie? = NSHTTPCookie(properties:properties)
...
http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다.insecure.example.com을 사용한 Cookie Poisoning 공격을 수행하여 secure.example.com의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다./")에서 액세스할 수 있도록 쿠키를 설정합니다. 그러면 도메인의 모든 웹 응용 프로그램에 대해 쿠키가 노출됩니다. 쿠키는 흔히 세션 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의 쿠키를 덮어쓰는, 자체의 지나치게 광범위한 쿠키를 생성할 수도 있습니다..example.com"과 같은 기본 도메인이 되도록 설정합니다. 그러나 그렇게 하면 기본 도메인 이름 및 모든 하위 도메인의 모든 웹 응용 프로그램에 세션 쿠키가 노출됩니다. 세션 쿠키를 누출하면 계정이 손상될 수 있습니다.http://secure.example.com/에서 배포한 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 쿠키를 설정한다고 가정하겠습니다.
server.servlet.session.cookie.domain=.example.com
http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다..example.com"과 같은 기본 도메인이 되도록 설정합니다. 그러면 기본 도메인 및 모든 하위 도메인의 모든 웹 응용 프로그램에 쿠키가 노출됩니다. 응용 프로그램 전반에서 세션 쿠키를 공유하면 한 응용 프로그램의 취약점이 다른 응용 프로그램을 손상시킬 수 있습니다.http://secure.example.com/에서 배포한 안전한 응용 프로그램이 있고 이 응용 프로그램이 사용자가 로그인할 때 ".example.com" 도메인을 사용하여 세션 쿠키를 설정한다고 가정하겠습니다.
session_set_cookie_params(0, "/", ".example.com", true, true);
http://insecure.example.com/에 덜 안전한 다른 응용 프로그램이 있으며 여기에는 Cross-Site Scripting 취약점이 있다고 가정합니다. http://insecure.example.com을 찾아보는 http://secure.example.com에 인증된 모든 사용자는 http://secure.example.com에서 해당 세션 쿠키를 노출할 위험이 있습니다./")가 되도록 세션 쿠키를 설정합니다. 그러면 동일한 도메인의 모든 웹 응용 프로그램에 대해 쿠키가 노출됩니다. 세션 쿠키가 누출되면 공격자가 도메인에서 임의의 응용 프로그램의 취약점을 사용하여 세션 쿠키를 도용할 수 있기 때문에 계정이 손상될 수 있습니다.http://communitypages.example.com/MyForum에서 배포된 포럼 응용 프로그램이 있고 이 응용 프로그램이 사용자가 포럼에 로그인할 때 "/" 경로를 가진 세션 쿠키를 설정한다고 가정하겠습니다. 예를 들어, 다음과 같습니다.
server.servlet.session.cookie.path=/
http://communitypages.example.com/EvilSite에서 다른 응용 프로그램을 생성하여 포럼에서 이 사이트에 대한 링크를 게시한다고 가정하겠습니다. 포럼의 사용자가 이 링크를 클릭하면 브라우저는 /MyForum에서 설정된 세션 쿠키를 /EvilSite에서 실행 중인 응용 프로그램으로 전송합니다. 공격자는 /MyForum에서 사용자가 제공한 세션 쿠키를 사용하여 /EvilSite를 탐색하는 임의의 포럼 사용자 계정을 손상시킬 수 있습니다./")가 되도록 세션 쿠키를 설정합니다. 그러면 동일한 도메인의 모든 웹 응용 프로그램에 대해 쿠키가 노출됩니다. 세션 쿠키가 누출되면 공격자가 도메인에서 임의의 응용 프로그램의 취약점을 사용하여 세션 쿠키를 도용할 수 있기 때문에 계정이 손상될 수 있습니다.http://communitypages.example.com/MyForum에서 배포된 포럼 응용 프로그램이 있고 이 응용 프로그램이 사용자가 포럼에 로그인할 때 "/" 경로를 가진 세션 쿠키를 설정한다고 가정하겠습니다.
session_set_cookie_params(0, "/", "communitypages.example.com", true, true);
http://communitypages.example.com/EvilSite에서 다른 응용 프로그램을 생성하여 포럼에서 이 사이트에 대한 링크를 게시한다고 가정하겠습니다. 포럼의 사용자가 이 링크를 클릭하면 브라우저는 /MyForum에서 설정된 세션 쿠키를 /EvilSite에서 실행 중인 응용 프로그램으로 전송합니다. 공격자는 세션 쿠키를 도용하여 /EvilSite를 방문한 임의의 포럼 사용자 계정을 손상시킬 수 있습니다.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)
...
server.servlet.session.cookie.persistent=true
session_set_cookie_params(time()+60*60*24*365*10, "/", "www.example.com", false, true);
Secure 플래그를 true로 설정하지 않은 상태에서 만들어집니다.Secure 플래그를 지원합니다. 플래그가 설정되면 브라우저는 HTTPS를 통해 쿠키를 전송하기만 합니다. 암호화되지 않은 채널을 통해 쿠키를 전송하면 네트워크 염탐 공격에 노출될 수 있으므로 안전한 플래그를 사용하는 것이 쿠키의 값 자격 증명을 유지하는 데 도움을 줍니다. 이것은 쿠키가 개인 정보를 포함하거나 세션 ID를 전하는 경우 특히 중요합니다.Secure 플래그를 설정하지 않고 응답에 추가되는 구성입니다.
...
<configuration>
<system.web>
<authentication mode="Forms">
<forms requireSSL="false" loginUrl="login.aspx">
</forms>
</authentication>
</system.web>
</configuration>
...
Secure 플래그를 설정하지 않는 경우, HTTPS 요청 중에 전송된 쿠키는 다음 HTTP 요청 중에도 전송됩니다. 암호화되지 않은 무선 연결을 통한 네트워크 트래픽 염탐은 공격자에게는 간단한 작업이므로 HTTP를 통한 쿠키(특히 세션 ID가 있는 쿠키) 전송은 응용 프로그램을 손상시킬 수 있습니다.Secure 플래그를 지원합니다. 플래그가 설정되면 브라우저는 HTTPS를 통해 쿠키를 전송하기만 합니다. 암호화되지 않은 채널을 통해 쿠키를 전송하면 네트워크 염탐 공격에 노출될 수 있으므로 안전한 플래그를 사용하는 것이 쿠키의 값 자격 증명을 유지하는 데 도움을 줍니다. 이것은 쿠키가 개인 정보를 포함하거나 세션 ID를 전하는 경우 특히 중요합니다.Secure 플래그를 끕니다.
server.servlet.session.cookie.secure=false
Secure 플래그를 설정하지 않는 경우, HTTPS 요청 중에 전송된 쿠키는 다음 HTTP 요청 중에도 전송됩니다. 그러면 공격자가 암호화되지 않은 네트워크 트래픽을 염탐(무선 네트워크를 통하는 경우 특히 쉬움)하여 쿠키를 손상시킬 수 있습니다.Secure 플래그를 true로 설정하지 않고 세션 쿠키를 생성합니다.Secure 플래그를 지원합니다. 플래그가 설정되면 브라우저는 HTTPS를 통해 쿠키를 전송하기만 합니다. 암호화되지 않은 채널을 통해 쿠키를 전송하면 네트워크 염탐 공격에 노출될 수 있으므로 안전한 플래그를 사용하는 것이 쿠키의 값 자격 증명을 유지하는 데 도움을 줍니다. 이것은 쿠키가 개인 정보를 포함하거나 세션 ID를 전하는 경우 특히 중요합니다.Secure 플래그를 설정하지 않고 쿠키를 응답에 추가합니다.
...
setcookie("emailCookie", $email, 0, "/", "www.example.com");
...
Secure 플래그를 설정하지 않는 경우, HTTPS 요청 중에 전송된 쿠키는 다음 HTTP 요청 중에도 전송됩니다. 그러면 공격자가 암호화되지 않은 네트워크 트래픽을 염탐(무선 네트워크를 통하는 경우 특히 쉬움)하여 쿠키를 손상시킬 수 있습니다.SESSION_COOKIE_SECURE 속성을 True로 명시적으로 설정하지 않거나 False로 설정합니다.Secure 플래그를 지원합니다. 플래그가 설정되면 브라우저는 HTTPS를 통해 쿠키를 전송하기만 합니다. 암호화되지 않은 채널을 통해 쿠키를 전송하면 네트워크 염탐 공격에 노출될 수 있으므로 안전한 플래그를 사용하는 것이 쿠키의 값 자격 증명을 유지하는 데 도움을 줍니다. 이는 쿠키가 개인 데이터 또는 세션 ID를 포함하거나 CSRF 토큰을 전하는 경우 특히 중요합니다.Secure 비트를 명시적으로 설정하지 않습니다.
...
MIDDLEWARE = (
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'django.middleware.common.CommonMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'csp.middleware.CSPMiddleware',
'django.middleware.security.SecurityMiddleware',
...
)
...
Secure 플래그를 설정하지 않는 경우, HTTPS 요청 중에 전송된 쿠키는 다음 HTTP 요청 중에도 전송됩니다. 그러면 공격자가 암호화되지 않은 네트워크 트래픽을 염탐(무선 네트워크를 통하는 경우 특히 쉬움)하여 쿠키를 손상시킬 수 있습니다.
...
<cfquery name = "GetSSNs" dataSource = "users"
username = "scott" password = "tiger">
SELECT SSN
FROM Users
</cfquery>
...
...
Credentials.basic("hardcoded-username", password);
...
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 공격입니다. 이는 응용 프로그램이 해당 요청의 출처를 확인하는 방법을 가지고 있지 않기 때문입니다. 모든 요청은 사용자가 선택한 적법한 작업이거나 공격자가 설정한 허위 작업일 가능성이 있습니다. 공격자는 허위 요청이 생성하는 웹 페이지를 보지 못하므로 이 공격 기법은 응용 프로그램의 상태를 변경하는 요청의 경우에만 유용합니다.
@GetMapping("/ai")
String generation(String userInput) {
return this.chatClient.prompt()
.user(userInput)
.call()
.content();
}
message에서 응답을 검색하여 사용자에게 표시합니다.
const openai = new OpenAI({
apiKey: ...,
});
const chatCompletion = await openai.chat.completions.create(...);
message = res.choices[0].message.content
console.log(chatCompletion.choices[0].message.content)
val chatCompletionRequest = ChatCompletionRequest(
model = ModelId("gpt-3.5-turbo"),
messages = listOf(...)
)
val completion: ChatCompletion = openAI.chatCompletion(chatCompletionRequest)
response.getOutputStream().print(completion.choices[0].message)
message에서 응답을 검색하여 사용자에게 표시합니다.
client = openai.OpenAI()
res = client.chat.completions.create(...)
message = res.choices[0].message.content
self.writeln(f"<p>{message}<\p>")
chatService.createCompletion(
text,
settings = CreateCompletionSettings(...)
).map(completion =>
val html = Html(completion.choices.head.text)
Ok(html) as HTML
)
...
text/html MIME 유형을 지정해야 합니다. 따라서 응답이 이 MIME 유형을 사용하거나 브라우저가 응답을 HTML 또는 스크립트를 실행할 수 있는 다른 문서(예: SVG 이미지(image/svg+xml), XML 문서(application/xml) 등)로 렌더링하게 만드는 다른 유형을 사용하는 경우에만 XSS가 가능합니다. application/octet-stream 같은 MIME 유형을 사용하여 응답을 제공할 때 HTML을 렌더링하지 않거나 스크립트를 실행하지 않습니다. 하지만 Internet Explorer와 같은 일부 브라우저는 Content Sniffing으로 알려진 동작을 수행합니다. 콘텐트 스니핑에서는 제공된 MIME 유형을 무시하고 응답의 콘텐트를 기준으로 올바른 MIME 유형을 추정하려고 시도합니다.text/html의 MIME 유형은 XSS 취약점으로 이어질 수 있는 MIME 유형 중 하나일 뿐입니다. SVG 이미지(image/svg+xml), XML 문서(application/xml) 등과 같은, 스크립트를 실행할 수 있는 다른 문서로 인해 브라우저가 콘텐트 스니핑을 수행하는지 여부와 관계없이 XSS 취약점이 발생할 수 있습니다. <html><body><script>alert(1)</script></body></html>과 같은 응답은 content-type 헤더가 application/octet-stream, multipart-mixed 등으로 설정되어 있어도 HTML로 렌더링될 수 있습니다.application/octet-stream 응답에 사용자 데이터를 반영합니다.
@RestController
public class SomeResource {
@RequestMapping(value = "/test", produces = {MediaType.APPLICATION_OCTET_STREAM_VALUE})
public String response5(@RequestParam(value="name") String name){
return name;
}
}
name 매개 변수를 <html><body><script>alert(1)</script></body></html>로 설정하여 요청을 전송하면 서버는 다음과 같은 응답을 생성합니다.
HTTP/1.1 200 OK
Content-Length: 51
Content-Type: application/octet-stream
Connection: Closed
<html><body><script>alert(1)</script></body></html>
text/html MIME 유형을 지정해야 합니다. 따라서 응답이 이 MIME 유형을 사용하거나 브라우저가 응답을 HTML 또는 스크립트를 실행할 수 있는 다른 문서(예: SVG 이미지(image/svg+xml), XML 문서(application/xml) 등)로 렌더링하게 만드는 다른 유형을 사용하는 경우에만 XSS가 가능합니다. application/json 같은 MIME 유형을 사용하여 응답을 제공할 때 HTML을 렌더링하거나 스크립트를 실행하지 않습니다. 하지만 Internet Explorer와 같은 일부 브라우저는 Content Sniffing으로 알려진 동작을 수행합니다. 콘텐트 스니핑에서는 제공된 MIME 유형을 무시하고 응답의 콘텐트를 기준으로 올바른 MIME 유형을 추정하려고 시도합니다.그러나 text/html의 MIME 유형은 XSS 취약점으로 이어질 수 있는 MIME 유형 중 하나일 뿐입니다.image/svg+xml), XML 문서(application/xml) 등과 같은, 스크립트를 실행할 수 있는 다른 문서로 인해 브라우저가 콘텐트 스니핑을 수행하는지 여부와 관계없이 XSS 취약점이 발생할 수 있습니다. <html><body><script>alert(1)</script></body></html>과 같은 응답은 content-type 헤더가 application/json으로 설정되어 있어도 HTML로 렌더링될 수 있습니다.application/json 응답에 사용자 데이터를 반영합니다.
def mylambda_handler(event, context):
name = event['name']
response = {
"statusCode": 200,
"body": "{'name': name}",
"headers": {
'Content-Type': 'application/json',
}
}
return response
name 매개 변수를 <html><body><script>alert(1)</script></body></html>로 설정하여 요청을 전송하면 서버는 다음과 같은 응답을 생성합니다.
HTTP/1.1 200 OK
Content-Length: 88
Content-Type: application/json
Connection: Closed
{'name': '<html><body><script>alert(1)</script></body></html>'}
eid를 읽어 사용자에게 표시합니다.
String queryString = Window.Location.getQueryString();
int pos = queryString.indexOf("eid=")+4;
HTML output = new HTML();
output.setHTML(queryString.substring(pos, queryString.length()));
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.eid를 읽고 사용자에게 표시합니다.예제 2: 다음의 HTML 형식을 고려해 보십시오.
<SCRIPT>
var pos=document.URL.indexOf("eid=")+4;
document.write(document.URL.substring(pos,document.URL.length));
</SCRIPT>
<div id="myDiv">
Employee ID: <input type="text" id="eid"><br>
...
<button>Show results</button>
</div>
<div id="resultsDiv">
...
</div>
$(document).ready(function(){
$("#myDiv").on("click", "button", function(){
var eid = $("#eid").val();
$("resultsDiv").append(eid);
...
});
});
eid인 텍스트 입력에서 직원 ID에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
let element = JSON.parse(getUntrustedInput());
ReactDOM.render(<App>
{element}
</App>);
Example 3에서 공격자가 getUntrustedInput()에서 파생된 전체 JSON을 제어할 수 있는 경우 React가 element를 구성 요소로 렌더링하도록 만들 수 있기 때문에 일반적인 Cross-Site Scripting 공격인 자체 제어 값으로 dangerouslySetInnerHTML을 이용하여 개체를 전달할 수 있습니다.
<attribute name="href" onInvalid="filterTag">
<regexp-list>
<regexp name="onsiteURL"/>
<regexp name="offsiteURL"/>
</regexp-list>
</attribute>
eid)를 읽고 이를 사용자에게 표시합니다.
String eid = Request["eid"];
...
EmployeeID.Text = eid;
EmployeeID는 다음과 같이 정의된 서버 쪽 ASP.NET 컨트롤입니다.
<form runat="server">
...
<asp:Label id="EmployeeID" runat="server"/>
...
</form>
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
...
string name = "";
using (SqlConnection conn = new SqlConnection(_ConnectionString))
{
string eid = Request["eid"];
SqlCommand cmd = new SqlCommand("SELECT * FROM emp WHERE id = @id", conn);
cmd.Parameters.AddWithValue("@id", eid);
conn.Open();
SqlDataReader objReader = cmd.ExecuteReader();
while (objReader.Read())
{
name = objReader["name"];
}
objReader.Close();
}
...
EmployeeName.Text = name;
EmployeeName는 다음과 같이 정의된 서버 쪽 ASP.NET 컨트롤입니다.
<form runat="server">
...
<asp:Label id="EmployeeName" runat="server"/>
...
</form>
Example 2에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 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 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.
...
WebView webview = (WebView) findViewById(R.id.webview);
webview.getSettings().setJavaScriptEnabled(true);
String url = this.getIntent().getExtras().getString("url");
webview.loadUrl(url);
...
url 값이 javascript:로 시작하면 그 뒤에 오는 JavaScript 코드가 WebView 내에 있는 웹 페이지의 컨텍스트에서 실행됩니다.eid를 읽어 사용자에게 표시합니다.
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id="+eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
}
%>
Employee Name: <%= name %>
Example 2에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1과 같이 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 3에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.
...
val webview = findViewById<View>(R.id.webview) as WebView
webview.settings.javaScriptEnabled = true
val url = this.intent.extras!!.getString("url")
webview.loadUrl(url)
...
url 값이 javascript:로 시작하면 그 뒤에 오는 JavaScript 코드가 WebView 내에 있는 웹 페이지의 컨텍스트에서 실행됩니다.eid를 읽은 다음 서블릿의 응답에서 사용자에게 값을 되돌려 주어 표시합니다.
val eid: String = request.getParameter("eid")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee ID: $eid")
...
out.close()
...
eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.
val stmt: Statement = conn.createStatement()
val rs: ResultSet = stmt.executeQuery("select * from emp where id=$eid")
rs.next()
val name: String = rs.getString("name")
...
val out: ServletOutputStream = response.getOutputStream()
out.print("Employee Name: $name")
...
out.close()
...
Example 2에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1과 같이 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 3에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.
...
@property (strong, nonatomic) NSString *webContentFromURL;
...
- (BOOL)application:(UIApplication *)application openURL:(NSURL *)url sourceApplication:(NSString *)sourceApplication annotation:(id)annotation {
...
[self setWebContentFromURL:[url host]];
...
...
...
@property (strong, nonatomic) WKWebView *webView;
...
AppDelegate *appDelegate = (AppDelegate *)[[UIApplication sharedApplication] delegate];
...
[_webView loadHTMLString:appDelegate.webContentFromURL] baseURL:nil];
...
...
@property (strong, nonatomic) WKWebView *webView;
@property (strong, nonatomic) UITextField *inputTextField;
...
[_webView loadHTMLString:_inputTextField.text baseURL:nil];
...
inputTextField 내의 텍스트에 표준 영숫자 텍스트만 있으면 문제없이 작동합니다. inputTextField 내의 텍스트에 메타 문자나 소스 코드가 포함되어 있으면 웹 브라우저에서 HTTP 응답을 표시할 때 입력을 코드로 실행할 수 있습니다.
...
@property (strong, nonatomic) WKWebView *webView;
...
NSFetchRequest *fetchRequest = [[NSFetchRequest alloc] init];
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Employee" inManagedObjectContext:context];
[fetchRequest setEntity:entity];
NSArray *fetchedObjects = [context executeFetchRequest:fetchRequest error:&error];
for (NSManagedObject *info in fetchedObjects) {
NSString msg = @"Hello, " + [info valueForKey:@"name"];
[_webView loadHTMLString:msg baseURL:nil]
...
}
...
Example 2에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서는 대상 응용 프로그램 외부의 소스에서 대상 응용 프로그램의 사용자 지정 URL 스키마를 사용하여 URL 요청을 생성하고, 이어서 URL 요청의 확인되지 않은 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 다시 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.Example 2에서는 데이터를 사용자가 제어할 수 있는 UI 구성 요소에서 직접 읽어 들여 HTTP 응답에 다시 적용합니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 3에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.
...
func application(app: UIApplication, openURL url: NSURL, options: [String : AnyObject]) -> Bool {
...
let name = getQueryStringParameter(url.absoluteString, "name")
let html = "Hi \(name)"
let webView = WKWebView()
webView.loadHTMLString(html, baseURL:nil)
...
}
func getQueryStringParameter(url: String?, param: String) -> String? {
if let url = url, urlComponents = NSURLComponents(string: url), queryItems = (urlComponents.queryItems as? [NSURLQueryItem]) {
return queryItems.filter({ (item) in item.name == param }).first?.value!
}
return nil
}
...
loadHTMLString:으로 전달되는 문자열은 사용자가 제어할 수 있고 WKWebView 내에서는 기본적으로 JavaScript가 활성화되므로 사용자는 앱의 사용자 지정 URL 스키마를 사용하는 요청을 통해 WKWebView에 임의의 콘텐트(실행 가능한 스크립트 포함)를 작성할 수 있습니다.
...
let webView : WKWebView
let inputTextField : UITextField
webView.loadHTMLString(inputTextField.text, baseURL:nil)
...
inputTextField 내의 텍스트에 표준 영숫자 텍스트만 있으면 문제없이 작동합니다. inputTextField 내의 텍스트에 메타 문자나 소스 코드가 포함되어 있으면 웹 브라우저에서 HTTP 응답을 표시할 때 입력을 코드로 실행할 수 있습니다.
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Employee", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
do {
let results = try managedContext.executeFetchRequest(fetchRequest)
let result : NSManagedObject = results.first!
let name : String = result.valueForKey("name")
let msg : String = "Hello, \(name)"
let webView : UIWebView = UIWebView()
webView.loadHTMLString(msg, baseURL:nil)
} catch let error as NSError {
print("Error \(error)")
}
Example 2에서처럼 이 코드는 name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 name의 값을 분명하게 응용 프로그램이 콘텐트를 관리하는 데이터베이스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 name의 값이 사용자가 제공하는 데이터에서 오는 경우 데이터베이스는 악성 콘텐트의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Persistent(또는 Stored) XSS라고 하는데 데이터 저장소가 사용하는 간접 참조 때문에 위협을 식별하기 어렵고 공격이 여러 사용자에게 가해질 가능성이 커지기 때문에 더욱 위험합니다. XSS는 방문자에게 "방명록"을 제공하는 웹 사이트에서 이런 형태로 시작되었습니다. 공격자가 방명록 항목에 JavaScript를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.Example 1에서는 대상 응용 프로그램 외부의 소스에서 대상 응용 프로그램의 사용자 지정 URL 스키마를 사용하여 URL 요청을 생성하고, 이어서 URL 요청의 확인되지 않은 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 다시 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.Example 2에서는 데이터를 사용자가 제어할 수 있는 UI 구성 요소에서 직접 읽어 들여 HTTP 응답에 다시 적용합니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.Example 3에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.
...
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 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.Origin 헤더를 확인하지 못하면 모든 악성 사이트가 사용자를 가장하여 사용자 모르게 양방향 WebSocket 연결을 설정할 수 있게 됩니다.Origin 헤더를 확인하지 못하면 모든 악성 사이트가 사용자를 가장하여 사용자 모르게 양방향 WebSocket 연결을 설정할 수 있게 됩니다.