VirtualLock을 사용하지 마십시오. 함수가 항상 구현되는 것은 아닙니다.VirtualLock 함수는 메모리의 페이지가 디스크에 페이지되는 것을 방지하기 위한 것입니다. 하지만, Windows 95/98/ME에서 이 함수는 스텁(stub)으로 구현되며 아무런 영향을 끼치지 않습니다. X-XSS-Protection을 1; mode=block으로 설정하면 이전 버전의 브라우저가 Cross-Site Scripting 취약점에 노출됩니다.X-XSS-Protection은 다른 브라우저에 채택되어 Microsoft에서 도입한 HTTP 헤더입니다. 이는 Cross-Site Scripting 공격이 성공하는 것을 중지하도록 돕기 위해 도입되었지만 의도치 않게 안전한 웹 사이트를 취약하게 만드는 취약점을 야기합니다[1]. 이 때문에 이 헤더는 이전 버전의 Internet Explorer에서 사용해서는 안 되며 0으로 설정하여 비활성화해야 합니다.Express 응용 프로그램에서 Helmet 미들웨어를 잘못 구성합니다.
var express = require('express');
var app = express();
var helmet = require('helmet');
...
app.use(helmet.xssFilter({ setOnOldIE: true}));
...
HtmlInputHidden hidden = new HtmlInputHidden();
Hidden hidden = new Hidden(element);
hidden 형식의 <input> 태그는 숨겨진 필드를 사용하고 있음을 나타냅니다.
<input type="hidden">
X-XSS-Protection 헤더는 최신 브라우저에서 기본적으로 활성화됩니다. 이 헤더 값을 false(0)로 설정하면 Cross-Site Scripting 보호가 비활성화됩니다.X-XSS-Protection 헤더가 명시적으로 비활성화되어 있어 Cross-Site Scripting 공격의 위험이 증가할 수 있습니다.X-XSS-Protection 헤더는 최신 브라우저에서 기본적으로 활성화됩니다. 이 헤더 값을 false(0)로 설정하면 Cross-Site Scripting 보호가 비활성화됩니다.
<http auto-config="true">
...
<headers>
...
<xss-protection xss-protection-enabled="false" />
</headers>
</http>
X-XSS-Protection 헤더가 명시적으로 비활성화되어 있어 cross-site scripting 공격의 위험이 증가할 수 있습니다.X-XSS-Protection 헤더는 최신 브라우저에서 기본적으로 활성화됩니다. 이 헤더 값을 false(0)로 설정하면 Cross-Site Scripting 보호가 비활성화됩니다.X-XSS-Protection 헤더가 명시적으로 비활성화되어 있어 cross-site scripting 공격의 위험이 증가할 수 있습니다.X-XSS-Protection 헤더는 최신 브라우저에서 기본적으로 활성화됩니다. 이 헤더 값을 false(0)로 설정하면 Cross-Site Scripting 보호가 비활성화됩니다.
...
var db = openDatabase('mydb', '1.0', 'Test DB', 2 * 1024 * 1024);
...
'mydb'로 추측할 수 있는 사람은 누구나 데이터베이스에 액세스할 수 있습니다.required 속성을 사용하여 입력 폼 필드가 필요한지 지정할 수 있습니다. 필드 유형을 지정하면 해당 유형에 대하여 입력이 확실히 검사됩니다. 정규식에 대하여 입력을 검사하는 사용자 지정 가능 pattern 속성까지 제공할 수 있습니다. 그러나 이 검증은 폼 태그의 novalidate 속성과 제출 입력 태그의 formnovalidate 속성 추가 시 비활성화됩니다.novalidate 속성을 통해 폼 검증을 비활성화합니다.예제 2: 다음 샘플은
<form action="demo_form.asp" novalidate="novalidate">
E-mail: <input type="email" name="user_email" />
<input type="submit" />
</form>
formnovalidate 속성을 통해 폼 검증을 비활성화합니다.
<form action="demo_form.asp" >
E-mail: <input type="email" name="user_email" />
<input type="submit" formnovalidate="formnovalidate"/>
</form>
SECURE_CROSS_ORIGIN_OPENER_POLICY = 'unsafe-none'
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);
}
...
}