Application_BeginRequest 메서드가 비어 있거나 X-Content-Type-Options를 nosniff로 설정하는 함수 호출을 포함하지 않거나 해당 헤더를 제거하려고 합니다.X-Content-Type-Options: nosniff라는 HTTP 헤더를 사용해야 합니다.X-Content-Type-Options를 nosniff로 설정하지 않습니다.X-Content-Type-Options: nosniff를 사용합니다.net.http.DetectContentType()을 사용하여 응답 Content-Type을 결정합니다.
...
resp, err := http.Get("http://example.com/")
if err != nil {
// handle error
}
defer resp.Body.Close()
body, err := ioutil.ReadAll(resp.Body)
content_type := DetectContentType(body)
...
X-Content-Type-Options를 nosniff로 설정하거나 이 보안 헤더를 명시적으로 비활성화하지 않습니다.X-Content-Type-Options: nosniff라는 HTTP 헤더를 사용해야 합니다.
<http auto-config="true">
...
<headers>
...
<content-type-options disabled="true"/>
</headers>
</http>
X-Content-Type-Options를 nosniff로 설정하거나 이 보안 헤더를 명시적으로 비활성화하지 않습니다.X-Content-Type-Options: nosniff라는 HTTP 헤더를 사용해야 합니다.X-Content-Type-Options를 nosniff로 설정하거나 이 보안 헤더를 명시적으로 비활성화하지 않습니다.X-Content-Type-Options: nosniff라는 HTTP 헤더를 사용해야 합니다.script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src.*를 사용할 수도 있습니다. 지정자를 반드시 사용해야 하는 것은 아닙니다. 브라우저는 목록에 나열되지 않은 지정자에 대해 모든 소스를 허용하기도 하고 선택적 default-src 지정자에서 값을 파생하기도 합니다. 또한, 이 헤더의 사양은 시간이 지남에 따라 발전해 왔습니다. Firefox(버전 23까지)와 IE(버전 10까지)에서는 X-Content-Security-Policy로 구현되어 있었으며 Chrome(버전 25까지)에서는 X-Webkit-CSP로 구현되어 있었습니다. 하지만 이제는 새 표준 이름인 Content Security Policy를 사용하기 위해 두 이름 모두 더 이상 사용되지 않습니다. 지정자의 수, 더 이상 사용되지 않는 2개의 대체 이름, 그리고 단일 헤더에서 여러 번 나타나는 동일한 헤더와 반복되는 지정자가 처리되는 방식을 감안하면 개발자가 이 헤더를 잘못 구성할 확률이 높습니다.unsafe-inline 또는 unsafe-eval이 포함된 지정자는 CSP를 사용하는 목적을 무효화합니다.script-src 지정자가 설정되어 있지만 nonce 스크립트는 구성되어 있지 않습니다.frame-src가 설정되어 있지만 sandbox는 구성되어 있지 않습니다.django-csp 구성에서는 안전하지 않은 unsafe-inline 및 unsafe-eval 지정자를 사용하여 인라인 스크립트 및 코드 평가를 허용합니다.
...
MIDDLEWARE = (
...
'csp.middleware.CSPMiddleware',
...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...
X-Frame-Options 헤더가 포함됩니다. 이 헤더를 사용하지 않거나 설정하지 않으면 cross-frame 관련 취약점이 발생할 수 있습니다.X-Frame-Options 헤더를 사용하지 않도록 Spring Security로 보호된 응용 프로그램을 구성합니다.
<http auto-config="true">
...
<headers>
...
<frame-options disabled="true"/>
</headers>
</http>
script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src. 이러한 8개의 지정자는 사이트가 해당 지정자에서 관여하는 기능에 접근할 수 있는 도메인을 지정하는 값으로 소스 목록을 사용합니다. 개발자는 전체 또는 일부 소스를 나타내기 위해 와일드카드인 *를 사용할 수도 있습니다. 'unsafe-inline' 및 'unsafe-eval'과 같은 추가 소스 목록 키워드를 사용하면 스크립트 실행을 보다 세밀하게 제어할 수 있지만 잠재적으로 유해합니다. 지정자를 반드시 사용해야 하는 것은 아닙니다. 브라우저는 목록에 나열되지 않은 지정자에 대해 모든 소스를 허용하기도 하고 선택적 default-src 지정자에서 값을 파생하기도 합니다. 또한, 이 헤더의 사양은 시간이 지남에 따라 발전해 왔습니다. Firefox 버전 23 이하 및 IE 버전 10 이하에서는 X-Content-Security-Policy로, Chrome 버전 25 이하에서는 X-Webkit-CSP로 구현되었습니다. 하지만 이제는 새 표준 이름인 Content Security Policy를 사용하므로 이러한 두 이름은 더 이상 사용되지 않습니다. 지정자의 수, 더 이상 사용되지 않는 2개의 대체 이름, 그리고 단일 헤더에서 여러 번 나타나는 동일한 헤더와 반복되는 지정자가 처리되는 방식을 감안하면 개발자가 이 헤더를 잘못 구성할 확률이 높습니다.default-src 지정자를 설정합니다.
<http auto-config="true">
...
<headers>
...
<content-security-policy policy-directives="default-src '*'" />
</headers>
</http>
script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src. 이러한 8개의 지정자는 사이트가 해당 지정자에서 관여하는 기능에 접근할 수 있는 도메인을 지정하는 값으로 소스 목록을 사용합니다. 개발자는 전체 또는 일부 소스를 나타내기 위해 와일드카드인 *를 사용할 수도 있습니다. 'unsafe-inline' 및 'unsafe-eval'과 같은 추가 소스 목록 키워드를 사용하면 스크립트 실행을 보다 세밀하게 제어할 수 있지만 잠재적으로 유해합니다. 지정자를 반드시 사용해야 하는 것은 아닙니다. 브라우저는 목록에 나열되지 않은 지정자에 대해 모든 소스를 허용하기도 하고 선택적 default-src 지정자에서 값을 파생하기도 합니다. 또한, 이 헤더의 사양은 시간이 지남에 따라 발전해 왔습니다. Firefox 버전 23 이하 및 IE 버전 10 이하에서는 X-Content-Security-Policy로, Chrome 버전 25 이하에서는 X-Webkit-CSP로 구현되었습니다. 하지만 이제는 새 표준 이름인 Content Security Policy를 사용하므로 이러한 두 이름은 더 이상 사용되지 않습니다. 지정자의 수, 더 이상 사용되지 않는 2개의 대체 이름, 그리고 단일 헤더에서 여러 번 나타나는 동일한 헤더와 반복되는 지정자가 처리되는 방식을 감안하면 개발자가 이 헤더를 잘못 구성할 확률이 높습니다.*-src 지정자는 * 같이 지나치게 허용적인 정책으로 구성되어 왔습니다.django-csp 설정에서는 지나치게 허용적이며 안전하지 않은 default-src 지정자를 설정합니다.
...
MIDDLEWARE = (
...
'csp.middleware.CSPMiddleware',
...
)
...
CSP_DEFAULT_SRC = ("'self'", '*')
...
Access-Control-Allow-Origin이라는 새 HTTP 헤더가 정의될 경우 JavaScript가 도메인 전체의 데이터에 액세스할 수 있습니다. 이 헤더가 있는 경우, 웹 서버는 cross-origin 요청을 사용하여 해당 도메인에 액세스할 수 있는 다른 도메인을 정의합니다. 그러나, 지나치게 허용적인 CORS 정책을 사용하면 악성 응용 프로그램이 부적절한 방법으로 피해자 응용 프로그램과 통신하여 스푸핑, 데이터 도난, 릴레이 및 기타 공격으로 이어질 수 있기 때문에 헤더 정의 시 주의해야 합니다.
Response.AppendHeader("Access-Control-Allow-Origin", "*");
*를 Access-Control-Allow-Origin 헤더의 값으로 사용하는 것은 응용 프로그램의 데이터가 임의의 도메인에서 실행 중인 JavaScript에 접근할 수 있음을 나타냅니다.Access-Control-Allow-Origin이라는 새 HTTP 헤더가 정의될 경우 JavaScript가 도메인 전체의 데이터에 액세스할 수 있습니다. 이 헤더가 있는 경우, 웹 서버는 cross-origin 요청을 사용하여 해당 도메인에 액세스할 수 있는 다른 도메인을 정의합니다. 그러나, 지나치게 허용적인 CORS 정책을 사용하면 악성 응용 프로그램이 부적절한 방법으로 피해자 응용 프로그램과 통신하여 스푸핑, 데이터 도난, 릴레이 및 기타 공격으로 이어질 수 있기 때문에 헤더 정의 시 주의해야 합니다.
<websocket:handlers allowed-origins="*">
<websocket:mapping path="/myHandler" handler="myHandler" />
</websocket:handlers>
*를 Access-Control-Allow-Origin 헤더의 값으로 사용하는 것은 응용 프로그램의 데이터가 임의의 도메인에서 실행 중인 JavaScript에 접근할 수 있음을 나타냅니다.Access-Control-Allow-Origin이라는 새 HTTP 헤더가 정의될 경우 JavaScript가 도메인 전체의 데이터에 액세스할 수 있습니다. 이 헤더가 있는 경우, 웹 서버는 cross-origin 요청을 사용하여 해당 도메인에 액세스할 수 있는 다른 도메인을 정의합니다. 그러나, 지나치게 허용적인 CORS 정책을 사용하면 악성 응용 프로그램이 부적절한 방법으로 피해자 응용 프로그램과 통신하여 스푸핑, 데이터 도난, 릴레이 및 기타 공격으로 이어질 수 있기 때문에 헤더 정의 시 주의해야 합니다.
<?php
header('Access-Control-Allow-Origin: *');
?>
*를 Access-Control-Allow-Origin 헤더의 값으로 사용하는 것은 응용 프로그램의 데이터가 임의의 도메인에서 실행 중인 JavaScript에 접근할 수 있음을 나타냅니다.Access-Control-Allow-Origin이라는 새 HTTP 헤더가 정의될 경우 JavaScript가 도메인 전체의 데이터에 액세스할 수 있습니다. 이 헤더가 있는 경우, 웹 서버는 cross-origin 요청을 사용하여 해당 도메인에 액세스할 수 있는 다른 도메인을 정의합니다. 그러나, 지나치게 허용적인 CORS 정책을 사용하면 악성 응용 프로그램이 부적절한 방법으로 피해자 응용 프로그램과 통신하여 스푸핑, 데이터 도난, 릴레이 및 기타 공격으로 이어질 수 있기 때문에 헤더 정의 시 주의해야 합니다.
response.addHeader("Access-Control-Allow-Origin", "*")
*를 Access-Control-Allow-Origin 헤더의 값으로 사용하는 것은 응용 프로그램의 데이터가 임의의 도메인에서 실행 중인 JavaScript에 접근할 수 있음을 나타냅니다.Access-Control-Allow-Origin이라는 새 HTTP 헤더가 정의될 경우 JavaScript가 도메인 전체의 데이터에 액세스할 수 있습니다. 이 헤더가 있는 경우, 웹 서버는 cross-origin 요청을 사용하여 해당 도메인에 액세스할 수 있는 다른 도메인을 정의합니다. 그러나, 지나치게 허용적인 CORS 정책을 사용하면 악성 응용 프로그램이 부적절한 방법으로 피해자 응용 프로그램과 통신하여 스푸핑, 데이터 도난, 릴레이 및 기타 공격으로 이어질 수 있기 때문에 헤더 정의 시 주의해야 합니다.
play.filters.cors {
pathPrefixes = ["/some/path", ...]
allowedOrigins = ["*"]
allowedHttpMethods = ["GET", "POST"]
allowedHttpHeaders = ["Accept"]
preflightMaxAge = 3 days
}
*를 Access-Control-Allow-Origin 헤더의 값으로 사용하는 것은 응용 프로그램의 데이터가 임의의 도메인에서 실행 중인 JavaScript에 액세스할 수 있음을 나타냅니다.Access-Control-Allow-Origin이라는 새 HTTP 헤더가 정의될 경우 JavaScript가 도메인 전체의 데이터에 액세스할 수 있습니다. 이 헤더가 있는 경우, 웹 서버는 cross-origin 요청을 사용하여 해당 도메인에 액세스할 수 있는 다른 도메인을 정의합니다. 그러나, 지나치게 허용적인 CORS 정책을 사용하면 악성 응용 프로그램이 부적절한 방법으로 피해자 응용 프로그램과 통신하여 스푸핑, 데이터 도난, 릴레이 및 기타 공격으로 이어질 수 있기 때문에 헤더 정의 시 주의해야 합니다.
Response.AddHeader "Access-Control-Allow-Origin", "*"
*를 Access-Control-Allow-Origin 헤더의 값으로 사용하는 것은 응용 프로그램의 데이터가 임의의 도메인에서 실행 중인 JavaScript에 접근할 수 있음을 나타냅니다.
WebMessage message = new WebMessage(WEBVIEW_MESSAGE);
webview.postWebMessage(message, Uri.parse("*"));
*를 사용하면 스크립트가 원본에 상관없이 창에 메시지를 전송 중이라는 의미입니다.
o.contentWindow.postMessage(message, '*');
*를 사용하면 스크립트가 원본에 상관없이 창에 메시지를 전송 중이라는 의미입니다.Unsafe-URL로 설정하면 응용 프로그램이 민감한 사이트 및 사용자 데이터(세션 토큰, 사용자 이름 및 암호 포함)를 타사 사이트에 노출시킬 수 있습니다.Referrer-Policy 헤더는 referrer 헤더와 관련된 브라우저 동작을 제어하기 위해 도입되었습니다. Unsafe-URL 옵션을 사용하면 모든 제한이 제거되고 모든 요청과 함께 referrer 헤더를 보낼 수 있습니다.
<http auto-config="true">
...
<headers>
...
<referrer-policy policy="unsafe-url"/>
</headers>
</http>
Content-Security-Policy-Report-Only 헤더는 웹 응용 프로그램 작성자 및 관리자가 보안 정책을 적용하지 않고 모니터링할 수 있는 기능을 제공합니다. 이 헤더는 일반적으로 사이트의 보안 정책을 실험 및/또는 개발할 때 사용됩니다. 정책이 유효하다고 판단되면 Content-Security-Policy 헤더 필드를 대신 사용하여 정책을 적용할 수 있습니다.Report-Only 모드에서 Content Security Policy를 설정합니다.
<http auto-config="true">
...
<headers>
...
<content-security-policy report-only="true" policy-directives="default-src https://content.cdn.example.com" />
</headers>
</http>
Content-Security-Policy-Report-Only 헤더는 웹 응용 프로그램 작성자 및 관리자가 보안 정책을 적용하지 않고 모니터링할 수 있는 기능을 제공합니다. 이 헤더는 일반적으로 사이트의 보안 정책을 실험 및/또는 개발할 때 사용됩니다. 정책이 유효하다고 판단되면 Content-Security-Policy 헤더를 대신 사용하여 정책을 적용할 수 있습니다.Report-Only 모드에서 Content Security Policy를 설정합니다.
response.content_security_policy_report_only = "*"
...
String lang = Request.Form["lang"];
WebClient client = new WebClient();
client.BaseAddress = url;
NameValueCollection myQueryStringCollection = new NameValueCollection();
myQueryStringCollection.Add("q", lang);
client.QueryString = myQueryStringCollection;
Stream data = client.OpenRead(url);
...
en&poll_id=1 같은 lang을 제공할 가능성을 고려하지 않았기 때문에 공격자는 마음대로 poll_id를 변경할 수 있게 됩니다.
...
String lang = request.getParameter("lang");
GetMethod get = new GetMethod("http://www.example.com");
get.setQueryString("lang=" + lang + "&poll_id=" + poll_id);
get.execute();
...
en&poll_id=1 같은 lang을 제공할 가능성을 고려하지 않았기 때문에 공격자는 마음대로 poll_id를 변경할 수 있게 됩니다.
<%
...
$id = $_GET["id"];
header("Location: http://www.host.com/election.php?poll_id=" . $id);
...
%>
name=alice를 지정했지만 name=alice&를 더 추가했으며, 첫 번째 것을 가져오는 서버에서 이것이 사용되면 alice로 가장하여 이 사용자의 계정에 대한 추가 정보를 획득할 수 있습니다.
<authorization>
<allow verbs="GET,POST" users="admin"/>
<deny verbs="GET,POST"users="*" />
</authorization>
<security-constraint>
<display-name>Admin Constraint</display-name>
<web-resource-collection>
<web-resource-name>Admin Area</web-resource-name>
<url-pattern>/pages/index.jsp</url-pattern>
<url-pattern>/admin/*.do</url-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
</web-resource-collection>
<auth-constraint>
<description>only admin</description>
<role-name>admin</role-name>
</auth-constraint>
</security-constraint>
<http-method> 태그에 명시적으로 정의되지 않으므로 HEAD 요청으로 GET 또는 POST 요청을 대신하여 관리 기능이 수행 가능합니다. 관리 기능을 실행하기 위한 HEAD 요청의 경우 조건 3이 유지되어야 합니다. 즉, 응용 프로그램이 POST 이외의 동사를 기반으로 명령을 수행해야 합니다. 일부 웹/응용 프로그램 서버는 임의의 비표준 HTTP verb를 허용하고 GET 요청을 받은 것처럼 응답합니다. 그런 경우, 공격자는 요청에서 임의의 verb를 사용하여 관리 페이지를 볼 수 있습니다.
GET /admin/viewUsers.do HTTP/1.1
Host: www.example.com
FOO /admin/viewUsers.do HTTP/1.1
Host: www.example.com
rawmemchr() 호출에서 신뢰할 수 없는 명령줄 인수를 검색 버퍼로 사용합니다.
int main(int argc, char** argv) {
char* ret = rawmemchr(argv[0], 'x');
printf("%s\n", ret);
}
argv[0]의 부분 문자열을 인쇄하기 위한 것이지만 argv[0] 위에 있는 메모리 부분을 인쇄하게 됩니다.private 및 final을 선언한 다음 Set를 변경하는 메서드를 실수로 만듭니다.
@Immutable
public final class ThreeStooges {
private final Set stooges = new HashSet>();
...
public void addStooge(String name) {
stooges.add(name);
}
...
}
final이 아닙니다.Immutable 주석으로 주석 추가되었습니다. 비 final 필드는 값이 변경되도록 허용하여 클래스의 불변성을 침해합니다.final이 아닌 public으로 선언합니다.
@Immutable
public class ImmutableInteger {
public int value;
}
public 및 final을 선언합니다.
@Immutable
public final class ThreeStooges {
public final Set stooges = new HashSet();
...
}
memset()을 사용하여 메모리에서 암호를 초기화합니다.
void GetData(char *MFAddr) {
char pwd[64];
if (GetPasswordFromUser(pwd, sizeof(pwd))) {
if (ConnectToMainframe(MFAddr, pwd)) {
// Interaction with mainframe
}
}
memset(pwd, 0, sizeof(pwd));
}
pwd의 값을 덮어쓴 후 버퍼를 사용하지 않기 때문에 memset() 호출은 불필요한 저장 공간으로 간주되어 삭제됩니다[2]. 버퍼 pwd에는 민감한 값이 들어 있기 때문에 데이터가 메모리에 남아 있으면 응용 프로그램이 공격에 취약해질 수 있습니다. 공격자가 정확한 메모리 영역에 접근하게 되면 복구된 암호를 사용하여 시스템에 대한 제어를 얻을 수 있습니다.memset() 호출을 dead code로 해석합니다. 이 때, 문제는 많은 컴파일러 및 많은 프로그래밍 언어가 효율 개선을 이유로 이러한 보안 문제 또는 다른 보안 문제를 고려하지 않는다는 점입니다.
char *buf;
int len;
...
len = 1<<30;
if (buf+len < buf) //wrap check
[handle overflow]
buf + len은 2^32보다 커서 결과 값이 buf보다 작습니다. 그러나 포인터에 대한 산술 overflow는 정의되지 않은 동작이므로 일부 컴파일러는 buf + len >= buf를 가정하여 랩 확인을 최적화합니다. 이와 같이 최적화하면 이 블록 뒤에 오는 코드가 buffer overflow에 취약해질 수 있습니다.static files 응용 프로그램의 serve 보기를 노출합니다. Django 설명서에 따르면 다음과 같습니다.static files 도구는 대부분 정적 파일을 운영 환경에 성공적으로 배포하는 데 도움이 되도록 설계되어 있습니다. 일반적으로, 로컬로 개발하는 경우 상당한 처리 부담으로 작용하는 별도의 전용 정적 파일 서버가 여기에 해당합니다. 따라서 staticfiles 앱은 개발 시 파일을 로컬로 제공하는 데 사용할 수 있는 단순하면서도 정리되지 않은 도우미 보기가 함께 제공됩니다.DEBUG가 True로 설정되어 있는 경우에만 작동합니다.admin 응용 프로그램이 예측 가능한 URL로 배포되어 있습니다.
from django.conf.urls import patterns
from django.contrib import admin
admin.autodiscover()
urlpatterns = patterns('',
...
url(r'^admin/', include(admin.site.urls)),
...