1) 자동완성을 말함 2) 폼에 한 글자를 입력하면 문자열이 동적으로 표시되는 것을 뜻함 해당 취약점은 input 태그에 autocomplete = " off"로 설정하여 방지할 수 있음 * OWASP Top 10A3: 민감한 데이터 노출 (Sensitive Data Exposure) 포함
======================================================================= Unencrypted password form
The HTTP protocol by itself is clear text, meaning that any data that is transmitted via HTTP can be captured and the contents viewed. To keep data private, and prevent it from being intercepted, HTTP is often tunnelled through either Secure Sockets Layer (SSL), or Transport Layer Security (TLS). When either of these encryption standards are used it is referred to as HTTPS. Cyber-criminals will often attempt to compromise credentials passed from the client to the server using HTTP. This can be conducted via various different Man-in-The-Middle (MiTM) attacks or through network packet captures. Arachni discovered that the affected page contains a password input, however, the value of the field is not sent to the server utilising HTTPS. Therefore it is possible that any submitted credential may become compromised.
=L1====================================================================== Password field with auto-complete 1
In typical form-based web applications, it is common practice for developers to allow autocomplete within the HTML form to improve the usability of the page. With autocomplete enabled (default), the browser is allowed to cache previously entered form values. For legitimate purposes, this allows the user to quickly re-enter the same data when completing the form multiple times. When autocomplete is enabled on either/both the username and password fields, this could allow a cyber-criminal with access to the victim’s computer the ability to have the victim’s credentials automatically entered as the cyber-criminal visits the affected page. Arachni has discovered that the affected page contains a form containing a password field that has not disabled autocomplete.
Clickjacking (User Interface redress attack, UI redress attack, UI redressing) is a malicious technique of tricking a Web user into clicking on something different from what the user perceives they are clicking on, thus potentially revealing confidential information or taking control of their computer while clicking on seemingly innocuous web pages. The server didn’t return an X-Frame-Options header which means that this website could be at risk of a clickjacking attack. The X-Frame-Options HTTP response header can be used to indicate whether or not a browser should be allowed to render a page inside a frame or iframe. Sites can use this to avoid clickjacking attacks, by ensuring that their content is not embedded into other sites.
There are a number of HTTP methods that can be used on a webserver (OPTIONS, HEAD, GET, POST, PUT, DELETE etc.). Each of these methods perform a different function and each have an associated level of risk when their use is permitted on the webserver. A client can use the OPTIONS method within a request to query a server to determine which methods are allowed. Cyber-criminals will almost always perform this simple test as it will give a very quick indication of any high-risk methods being permitted by the server. Arachni discovered that several methods are supported by the server.
The server responded with a non 200 (OK) nor 404 (Not Found) status code. This is a non-issue, however exotic HTTP response status codes can provide useful insights into the behavior of the web application and assist with the penetration test.
HTTP by itself is a stateless protocol. Therefore the server is unable to determine which requests are performed by which client, and which clients are authenticated or unauthenticated.
The use of HTTP cookies within the headers, allows a web server to identify each individual client and can therefore determine which clients hold valid authentication, from those that do not. These are known as session cookies. When a cookie is set by the server (sent the header of an HTTP response) there are several flags that can be set to configure the properties of the cookie and how it is to be handled by the browser. The HttpOnly flag assists in the prevention of client side-scripts (such as JavaScript) accessing and using the cookie. This can help prevent XSS attacks targeting the cookies holding the client’s session token (setting the HttpOnly flag does not prevent, nor safeguard against XSS vulnerabilities themselves).
사용자가 로그인 한 이후에 브라우저가 내부적으로 자격 증명을 전송하는 모든 인증 프로토콜들은 위조 방지 토큰을 사용해야만 CSRF 공격을 방지할 수 있습니다. 그 대상에는, 폼 인증 같은 쿠키 기반 인증 프로토콜뿐만 아니라 기본 인증이나 다이제스트 인증도 포함됩니다.
또한, 모든 안전하지 않은 메서드들(POST, PUT, DELETE)에 위조 방지 토큰을 적용해야 합니다. 그리고, 안전한 메서드들도(GET, HEAD) 부작용을 일으키지 않는지 확인해야 합니다. 더군다나, CORS나 JSONP 같은 크로스-도메인 지원을 활성화시켰다면, GET 같은 안전한 메서드조차도 잠재적으로 CSRF 공격에 취약점을 갖게 되므로 공격자가 내부적으로 민감한 데이터를 읽을 수 있게 됩니다.
ASP.NET MVC의 위조 방지 토큰
Razor 페이지에 위조 방지 토큰을 추가하려면HtmlHelper.AntiForgeryToken도우미 메서드를 사용합니다:
보통 AJAX 요청은 HTML 폼 데이터 대신 JSON 데이터로 전송되는 경우가 많기 때문에, AJAX 요청에서는 폼 토큰이 문제가 될 수 있습니다. 이 문제를 해결할 수 있는 한 가지 방법은 토큰을 사용자 지정 HTTP 헤더에 담아서 전송하는 것입니다. 다음 코드는 Razor 구문으로 토큰들을 생성한 다음, 이를 AJAX 요청에 추가합니다.
이 HTML 폼의 action 어트리뷰트가 악의적인 사이트가 아닌, 취약한 사이트를 가리키고 있다는 점에 유의하시기 바랍니다. 바로 이런 특징 때문에, "크로스 사이트(Cross-Site)"라는 명칭이 붙은 것입니다.
사용자가 "submit" 버튼을 클릭합니다. 그러면, 브라우저가 요청에 인증 쿠키를 함께 포함시켜서 전송합니다.
이 요청은 서버에서 사용자의 인증 컨텍스트로 실행되므로, 인증된 사용자가 수행할 수 있는 모든 작업을 수행할 수 있습니다.
비록, 이 예제에서는 사용자가 직접 폼 버튼을 클릭해야만 공격이 수행되지만, 악의적인 페이지에서 AJAX 요청을 전송하는 스크립트를 자동으로 실행하도록 만드는 일도 매우 간단합니다. 더군다나, 악의적인 사이트에서 "https://"로 요청을 전송할 수도 있기 때문에, SSL을 사용하더라도 CSRF 공격을 방지할 수는 없습니다.
대부분의 경우 CSRF 공격은 쿠키를 이용해서 인증을 수행하는 사이트들을 대상으로 행해지는데, 그 이유는 브라우저가 자동으로 모든 관련된 쿠키들을 목적지 웹 사이트로 전송하기 때문입니다. 그러나, 그렇다고 해서 반드시 쿠키를 악용하는 형태로만 CSRF 공격이 이루어지는 것은 아닙니다.
가령, 기본 인증과 다이제스트(Digest) 인증도 역시 CSRF 공격에 취약합니다. 즉, 사용자가 기본 인증이나 다이제스트 인증으로 로그인 한 이후, 브라우저가 자동으로 세션 종료 시까지 자격 증명을 함께 전송하기 때문입니다.
HSTS란? 웹 브라우저가 HTTPS프로토콜만을 사용해서 서버와 통신하도록 하는 기능 일정시간 (max-age) 동안 HSTS 응답을 받은 웹사이트에 대해서 https 접속을 강제화
HTTPS 접속이 실패하는 경우 사이트 접근에 실패하게 됨. HSTS를 사용하는 대신 서버에서 HTTP 접속을 HTTPS로 redirect 시키는 방법이 있지만 HTTP 연결을 거쳐가는 것이기 때문에 쿠기 정보 탈취 등 보안에 취약함.
브라우저에서 http://d.com 으로 접속을 하면 웹서버에서 https로 접속하라고 보내옵니다.
HTST 설정 서버에서 HTTP 응답 헤더 필드에 'Strict-Transport-Security'라는 필드를 내려주면 브라우저는 그 사이트에 접속할 때 무조건 HTTPS로만 연결한다. HSTS가 적용되기 위해서는 서버도 헤더를 내려줘야하고 브라우저도 그 헤더에 따른 동작을 해야 함 HTTP 응답 헤더에 정보를 내려주면 된다.
preload list HSTS는 HTTPS로 웹 사이트에 접속하기 위해 적어도 한번 웹 서버와 통신을 해야하는데 통신 전에 미리 HTTPS로 접속하도록 목록을 미리 만들어 놓은 것. 브라우저에서 지원하는 기능이며, 브라우저 안에 기본적으로 내장되어 있는 사이트 목록들이 있음 서버가 헤더에 preload값을 내려주면 이 목록에 해당 사이트도 추가 됨. preload에 추가된 상디트는 서버가 HSTS헤더를 삭제해도 브라우저에는 설정이 유지된다. Chrome의 HSTS preload 리스트는 IE 등 타 브라우저에서도 활용하고 있는 것으로 파악 됨 preload list에 추가는 신중해야 함
HSTS 설정 시 주의사항 서버측 redirection 처리를 별도로 하지 않았는데 https로 자동 URL이 변경되는 경우가 있다면 HSTS 헤더를 의심 HSTS 헤더가 설정된 https url에 한번이라도 접속하면, HTTP 접속 시에도 HTTPS로 접속됨. Spring Security에서 디폴트로 HTTPS 요청 시에 HSTS 헤더값을 내려주도록 되어 있음.
