[출처] Testing for SSI Injection (OWASP-DV-009) 번역|작성자 ezno

http://blog.naver.com/PostView.nhn?blogId=ezno&logNo=130142796061&parentCategoryNo=&categoryNo=&viewDate=&isShowPopularPosts=false&from=postView

(Redirected from Testing for SSI Injection)

OWASP Testing Guide v3 Table of Contents

Web servers usually give developers the ability to add small pieces of dynamic code inside static HTML pages, without having to deal with full-fledged server-side or client-side languages. This feature is incarnated by the Server-Side Includes (SSI). In SSI injection testing, we test if it is possible to inject into the application data that will be interpreted by SSI mechanisms. A successful exploitation of this vulnerability allows an attacker to inject code into HTML pages or even perform remote code execution.

Server-Side Inlcudes는 웹서버가 사용자에게 페이지를 제공하기 전에 구문을 해석하도록 지시한다. Server-Side Inlcudes는 CGI프로그램을 작성하거나 혹은 server side 스크립트를 사용하는 내장된 간단한 언어들로, 오직 간단한 task들을 실행할 때 만 필요로 한다.

공통 SSI 구현은 외부의 파일들을 include 할 수 있는 명령어들을 제공하며, 웹 서버의 CGI 환경 변수를 설정하고 출력할 수 있고, 또한 외부의 CGI 스크립트 혹은 시스템 명령어들을 실행 할 수 있다.

SSI 지시를 static HTML 문서에 넣는 것은 다음과 같은 코드를 쓰는 것 만큼 간단하다 

현재의 시간을 출력

CGI 스크립트의 결과를 포함

파일 포함

시스템 명령어의 결과를 포함

만약 web server가 SSI 지원이 가능하면, 서버는 이러한 명령들을 실행 시킬 것이다. 기본 설정으로, 일반적으로, 대부분의 웹 서버들은 이러한 exec 명령들이 system 명령어를 실행시키도록 허용하지 않는다.

모든 bad 입력 값 검증(bad input validation) 상황처럼, 문제는 웹 애플리케이션의 사용자가 애플리케이션 혹은 웹 서버가 예측하지 못한 방식으로 데이터들을 제공하도록 허용할 때 발생한다.

SSI injection 때문에, 공격자가 애플리케이션에(혹은 서버에 직접적으로) 삽입된 동적으로 페이지를 생성 수 있는 input을 만들 수 있다면, 한 개 혹은 그 이상의 SSI 지시들을 parse 시킬 수 있다.

전통적인 스크립트 언어 injection 취약점과 매우 유사하다. 한가지 나은 점은 웹서버가 SSI를 허용하도록 설정해야 한다는 것이다.반면에, SSI Injection 취약점은 실행시키기 좀 더 간단하다. 왜냐하면 SSI 지시어들은 이해하기 쉽고, 파일의 내용을 출력하고 시스템 명령어를 실행 시킬 수 있을 만큼 강력하기 때문이다.

finding if the web server actually supports SSI directives.

웹서버가 SSI 지시어들을 허용하는지 대상 웹사이트들의 컨텐츠를 보면서 확인한다.

.shtml 파일이 있다면, SSI를 허용할 가능성이 높다.

아래와 같은 입력 값들이 유효하며, 입력값이 저장된 것을 확인한다.

To test if validation is insufficient, we can input, for example, a string like the following in an input form

다음과 같은 문자열을 input form에 입력하여 확인을 해본다.

이것은 XSS 취약점을 점검하는 것과 유사하다.

만약 애플리케이션이 취약하다면, 지시어들은 삽입이 되고 다음 페이지가 제공될 때 서버에 의해서 해석될 것이다. 따라서, Unix의password 파일이 컨텐츠에 포함될 것이다.

만약 웹 애플리케이션이 데이터들을 동적으로 페이지에게 생성하도록 한다면, 삽입은 HTTP 헤더에서 또한 수행할 수 있다.

If we have access to the application source code, we can quite easily find out:

If SSI directives are used. If they are, then the web server is going to have SSI support enabled, making SSI injection at least a potential issue to investigate.

Where user input, cookie content and HTTP headers are handled. The complete list of input vectors is then quickly determined.

How the input is handled, what kind of filtering is performed, what characters the application is not letting through, and how many types of encoding are taken into account.

Performing these steps is mostly a matter of using grep to find the right keywords inside the source code (SSI directives, CGI environment variables, variables assignment involving user input, filtering functions and so on).

Whitepapers

Apache Tutorial: "Introduction to Server Side Includes" - http://httpd.apache.org/docs/1.3/howto/ssi.html

Apache: "Module mod_include" - http://httpd.apache.org/docs/1.3/mod/mod_include.html

Apache: "Security Tips for Server Configuration" - http://httpd.apache.org/docs/1.3/misc/security_tips.html#ssi

Header Based Exploitation - http://www.cgisecurity.net/papers/header-based-exploitation.txt

SSI Injection instead of JavaScript Malware - http://jeremiahgrossman.blogspot.com/2006/08/ssi-injection-instead-of-javascript.html

Tools

Web Proxy Burp Suite - http://portswigger.net

Paros - http://www.parosproxy.org/index.shtml

WebScarab

String searcher: grep - http://www.gnu.org/software/grep, your favorite text editor

출처 : http://fendee.egloos.com/7097191

삭제 방지용으로 내용 붙여 넣는다.

출처: https://www.owasp.org/index.php/Unvalidated_Redirects_and_Forwards_Cheat_Sheet

Safe URL Redirects

When we want to redirect a user automatically to another page (without an action of the visitor such as clicking on a hyperlink) you might implement a code such as the following:

// 안전한 URL 리다이렉트는 아래와 같이 명확한 주소를 사용하는 경우이다.

Java

 response.sendRedirect("http://www.mysite.com");

PHP

 <?php
 /* Redirect browser */
 header("Location: http://www.mysite.com/");
 ?>

ASP.NET

  Response.Redirect("~/folder/Login.aspx")

Rails

   redirect_to login_path

In the examples above, the URL is being explicitly declared in the code and cannot be manipulated by an attacker.

Dangerous URL Redirects

The following examples demonstrate unsafe redirect and forward code.

Dangerous URL Redirect Example 1

The following Java code receives the URL from the 'url' GET parameter and redirects to that URL.

//위험한 URL 리다이렉트는 아래와 같이 사용자로부터 받은 파라미터 정보를 URL을 그대로 리다이렉트 시켰을 경우이다.

 response.sendRedirect(request.getParameter("url"));

The following PHP code obtains a URL from the query string and then redirects the user to that URL.

 $redirect_url = $_GET['url'];
 header("Location: " . $redirect_url);
 

A similar example of C# .NET Vulnerable Code:

 string url = request.QueryString["url"];
 Response.Redirect(url);

And in rails:

  redirect_to params[:url]

The above code is vulnerable to an attack if no validation or extra method controls are applied to verify the certainty of the URL. This vulnerability could be used as part of a phishing scam by redirecting users to a malicious site. If no validation is applied, a malicious user could create a hyperlink to redirect your users to an unvalidated malicious website, for example:

 http://example.com/example.php?url=http://malicious.example.com

The user sees the link directing to the original trusted site (example.com) and does not realize the redirection that could take place

Dangerous URL Redirect Example 2

ASP.NET MVC 1 & 2 websites are particularly vulnerable to open redirection attacks. In order to avoid this vulnerability, you need to apply MVC 3.

The code for the LogOn action in an ASP.NET MVC 2 application is shown below. After a successful login, the controller returns a redirect to the returnUrl. You can see that no validation is being performed against the returnUrl parameter.

Listing 1 – ASP.NET MVC 2 LogOn action in AccountController.cs

 [HttpPost]
 public ActionResult LogOn(LogOnModel model, string returnUrl)
 {
   if (ModelState.IsValid)
   {
     if (MembershipService.ValidateUser(model.UserName, model.Password))
     {
       FormsService.SignIn(model.UserName, model.RememberMe);
       if (!String.IsNullOrEmpty(returnUrl))
       {
         return Redirect(returnUrl);
       }
       else
       {
         return RedirectToAction("Index", "Home");
       }
     }
     else
     {
       ModelState.AddModelError("", "The user name or password provided is incorrect.");
     }
   }

   // If we got this far, something failed, redisplay form
   return View(model);
 }

Dangerous Forward Example

When applications allow user input to forward requests between different parts of the site, the application must check that the user is authorized to access the url, perform the functions it provides, and it is an appropriate url request. If the application fails to perform these checks, an attacker crafted URL may pass the application’s access control check and then forward the attacker to an administrative function that is not normally permitted.

http://www.example.com/function.jsp?fwd=admin.jsp

The following code is a Java servlet that will receive a GET request with a url parameter in the request to forward to the address specified in the url parameter. The servlet will retrieve the url parameter value from the request and complete the server-side forward processing before responding to the browser.

public class ForwardServlet extends HttpServlet 
{
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    String query = request.getQueryString();
    if (query.contains("fwd")) 
    {
      String fwd = request.getParameter("fwd");
      try 
      {
        request.getRequestDispatcher(fwd).forward(request, response);
      } 
      catch (ServletException e) 
      {
        e.printStackTrace();
      }
    }
  }
}

2세대 전기자동차 컬럼.pdf

아래 그림은 위 pdf 내용을 한장으로 요약한 자료입니다.