데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 정수에 의존하기 때문에 SQL injection 취약점에 취약하지 않은 문을 사용하여 지정한 ID([1])와 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

DATA: id TYPE i.
...
id = request->get_form_field( 'invoiceID' ).

CONCATENATE `INVOICEID = '` id `'` INTO cl_where.
SELECT *
    FROM invoices
    INTO CORRESPONDING FIELDS OF TABLE itab_invoices
    WHERE (cl_where).
ENDSELECT.
...

문제는 개발자가 ID의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL injection 취약성을 방지하는 매개 변수가 있는 SQL 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var id:int = int(Number(params["invoiceID"]));
        var query:String = "SELECT * FROM invoices WHERE id = :id";

        stmt.sqlConnection = conn;
        stmt.text = query;
        stmt.parameters[":id"] = id;
        stmt.execute();
        ...

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터는 SOQL/SOSL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제1: 다음 코드 예제에서, inputID 값은 사전 정의된 목록에서 제공되며, 바인딩 변수는 SOQL/SOSL injection을 방지하는 데 도움이 됩니다.

...
result = [SELECT Name, Phone FROM Contact WHERE (IsDeleted = false AND Id=:inputID)];
...

앞의 예제의 문제는 사전 정의된 ID 목록을 사용하여 사용자가 inputID의 값을 수정하지 못하도록 방지하기에는 불충분하다는 점입니다. 공격자가 인터페이스를 우회하고 다른 값으로 요청을 전송할 수 있는 경우 공격자는 다른 연락처 정보에 액세스할 수 있습니다. 이 예제의 코드는 사용자가 요청된 연락처에 액세스할 수 있는 권한이 있는지 확인하지 않으므로, 사용자가 볼 권한이 없는 경우에도 모든 연락처를 표시합니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.

2. 데이터는 LINQ 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 지정한 ID([1])와 일치하는 송장을 검색하는 LINQ 쿼리를 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...

int16 id = System.Convert.ToInt16(invoiceID.Text);
var invoice = OrderSystem.getInvoices()
	.Where(new Invoice { invoiceID = id });
...

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL injection 취약성을 예방하는 매개 변수가 있는 SQL 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...
CMyRecordset rs(&dbms);
rs.PrepareSQL("SELECT * FROM invoices WHERE id = ?");
rs.SetParam_int(0,atoi(r.Lookup("invoiceID").c_str()));
rs.SafeExecuteSQL();
...

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

데이터베이스 access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스의 데이터가 프로그램에 입력됩니다.


2. 데이터는 데이터베이스 이름의 값을 지정하는 데 사용됩니다.

데이터베이스 access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스의 데이터가 프로그램에 입력됩니다.


2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL Injection 취약점을 예방하는, 매개 변수가 있는 SQL 문을 사용하여 지정한 ID와 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다[1]. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...
id := request.FormValue("invoiceID")
query := "SELECT * FROM invoices WHERE id = ?";
rows, err := db.Query(query, id)
...

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL injection 취약성을 예방하는 매개 변수가 있는 SQL 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...
id = Integer.decode(request.getParameter("invoiceID"));
String query = "SELECT * FROM invoices WHERE id = ?";
PreparedStatement stmt = conn.prepareStatement(query);
stmt.setInt(1, id);
ResultSet results = stmt.execute();
...

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

모바일 환경에서는 데이터베이스 Access control 오류와 같은 전형적인 웹 응용 프로그램 취약성이 발생하지 않는다고 생각하는 사용자도 있습니다. 자기 자신을 공격하는 사용자는 없을 것이라 여기기 때문입니다. 그러나 모바일 플랫폼의 핵심 요소는 다양한 소스에서 다운로드되어 같은 장치에서 함께 실행되는 응용 프로그램이라는 점을 유념해야 합니다. 즉 금융 응용 프로그램과 맬웨어를 함께 실행할 가능성이 높으므로 프로세스 간 통신을 포함하도록 모바일 응용 프로그램의 공격 표면을 확장해야 합니다.

예제 2: 다음 코드는 Example 1을 Android 플랫폼에 맞게 조정합니다.

...
        String id = this.getIntent().getExtras().getString("invoiceID");
        String query = "SELECT * FROM invoices WHERE id = ?";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, new Object[]{id});
...

많은 최신 웹 프레임워크는 사용자 입력의 검증을 수행하기 위한 메커니즘을 제공합니다(Struts 및 Struts 2 포함). 확인되지 않은 입력의 소스를 강조하기 위해, Fortify 보안 코딩 규칙 팩은 악용 가능성을 낮추고 프레임워크 검증 메커니즘이 사용 중일 때마다 지원하는 증거에 포인터를 제공하여 Fortify Static Code Analyzer에서 보고한 문제의 우선 순위를 동적으로 재지정합니다. 이 기능을 Context-Sensitive Ranking(컨텍스트 감지 순위)이라고 부릅니다. Fortify 사용자의 감사 프로세스를 지원하기 위해, Fortify Software Security Research Group은 입력 소스에 적용된 검증 메커니즘에 따라 문제를 폴더로 그룹화하는 데이터 유효성 프로젝트 템플릿을 사용 가능하게 만듭니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL injection 취약성을 방지하는 매개 변수가 있는 SQL 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

	...
	var id = document.form.invoiceID.value;
	var query = "SELECT * FROM invoices WHERE id = ?";
	db.transaction(function (tx) {
		tx.executeSql(query,[id]);
		}
	)
	...

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터가 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL injection 취약성을 예방하는 매개 변수가 있는 SQL 문을 사용하여 지정한 ID와 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...

        NSManagedObjectContext *context = [appDelegate managedObjectContext];
        NSEntityDescription *entityDesc = [NSEntityDescription entityForName:@"Invoices" inManagedObjectContext:context];
        NSFetchRequest *request = [[NSFetchRequest alloc] init];
        [request setEntity:entityDesc];
        NSPredicate *pred = [NSPredicate predicateWithFormat:@"(id = %@)", invoiceId.text];
        [request setPredicate:pred];

        NSManagedObject *matches = nil;
        NSError *error;
        NSArray *objects = [context executeFetchRequest:request error:&error];

        if ([objects count] == 0) {
                 status.text = @"No records found.";
        } else {
                matches = [objects objectAtIndex:0];
                invoiceReferenceNumber.text = [matches valueForKey:@"invRefNum"];
                orderNumber.text = [matches valueForKey:@"orderNumber"];
                status.text = [NSString stringWithFormat:@"%d records found", [objects count]];
        }
        [request release];
...

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL injection 취약성을 예방하는 매개 변수가 있는 SQL 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

        ...
	$id = $_POST['id'];
	$query = "SELECT * FROM invoices WHERE id = ?";
	$stmt = $mysqli->prepare($query);
	$stmt->bind_param('ss',$id);
	$stmt->execute();
        ...

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

많은 최신 웹 프레임워크는 사용자 입력의 검증을 수행하기 위한 메커니즘을 제공합니다(Struts 및 Struts 2 포함). 확인되지 않은 입력의 소스를 강조하기 위해, Fortify 보안 코딩 규칙 팩은 악용 가능성을 낮추고 프레임워크 검증 메커니즘이 사용 중일 때마다 지원하는 증거에 포인터를 제공하여 Fortify Static Code Analyzer에서 보고한 문제의 우선 순위를 동적으로 재지정합니다. 이 기능을 Context-Sensitive Ranking(컨텍스트 감지 순위)이라고 부릅니다. Fortify 사용자의 감사 프로세스를 지원하기 위해, Fortify Software Security Research Group은 입력 소스에 적용된 검증 메커니즘에 따라 문제를 폴더로 그룹화하는 데이터 유효성 프로젝트 템플릿을 사용 가능하게 만듭니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.

2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL injection 취약성을 방지하는 매개 변수가 있는 SQL 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

procedure get_item (
itm_cv IN OUT ItmCurTyp,
id in varchar2)
is
open itm_cv for ' SELECT * FROM items WHERE ' ||
'invoiceID = :invid' ||
     	using id;
end get_item;

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL injection 취약성을 방지하는 매개 변수가 있는 SQL 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...
id = request.POST['id']
c = db.cursor()
stmt = c.execute("SELECT * FROM invoices WHERE id = %s", (id,))
...

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL injection 취약성을 방지하는 매개 변수가 있는 SQL 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...
id = req['invoiceID'].respond_to(:to_int)
query = "SELECT * FROM invoices WHERE id=?"
stmt = conn.prepare(query)
stmt.execute(id)
...

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

데이터베이스 액세스 제어 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL Injection 취약점을 예방하는, 매개 변수가 있는 SQL 문을 사용하여 지정한 ID와 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다[1]. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

  def searchInvoice(value:String) = Action.async { implicit request =>
    val result: Future[Seq[Invoice]] = db.run {
      sql"select * from invoices where id=$value".as[Invoice]
    }
    ...
  }

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터가 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL injection 취약성을 예방하는 매개 변수가 있는 SQL 문을 사용하여 지정한 ID와 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

...
let fetchRequest = NSFetchRequest()
let entity = NSEntityDescription.entityForName("Invoices", inManagedObjectContext: managedContext)
fetchRequest.entity = entity
let pred : NSPredicate = NSPredicate(format:"(id = %@)", invoiceId.text)
fetchRequest.setPredicate = pred
do {
    let results = try managedContext.executeFetchRequest(fetchRequest)
    let result : NSManagedObject = results.first!
    invoiceReferenceNumber.text = result.valueForKey("invRefNum")
    orderNumber.text = result.valueForKey("orderNumber")
    status.text = "\(results.count) records found"
} catch let error as NSError {
    print("Error \(error)")
}
...

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

데이터베이스 Access control 오류는 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 프로그램에 입력됩니다.


2. 데이터는 SQL 쿼리에서 기본 키의 값을 지정하는 데 사용됩니다.
예제 1: 다음 코드는 메타 문자를 이스케이프 처리하고 SQL injection 취약성을 예방하는 매개 변수가 있는 SQL 문을 사용하여 지정한 ID [1]에 일치하는 송장을 검색하는 SQL 쿼리를 생성하여 실행합니다. ID는 현재 인증된 사용자와 관련이 있는 모든 송장 목록에서 선택합니다.

	...
	id = Request.Form("invoiceID")
	strSQL = "SELECT * FROM invoices WHERE id = ?"
	objADOCommand.CommandText = strSQL
	objADOCommand.CommandType = adCmdText
	set objADOParameter = objADOCommand.CreateParameter("id" , adString, adParamInput, 0, 0)
	objADOCommand.Parameters("id") = id
	...

문제는 개발자가 id의 가능한 모든 값을 고려할 수 없다는 점입니다. 인터페이스에서 현재 사용자의 송장 ID 목록을 생성하더라도 공격자는 이 인터페이스를 무시하고 원하는 송장을 요청할 수 있습니다. 이 예제의 코드가 사용자가 요청한 송장에 접근할 수 있는 권한이 있는지 확인하지 않기 때문에 현재 사용자의 송장이 아닌 송장도 모두 표시합니다.

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 레지스트리 키 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.

...
CALL FUNCTION 'REGISTRY_GET'
  EXPORTING
     KEY   = 'APPHOME'
  IMPORTING
     VALUE = home.

CONCATENATE home INITCMD INTO cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...

Example 1의 코드는 레지스트리 항목 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 레지스트리에서 읽은 값을 확인하지 않기 때문에 공격자가 레지스트리 키 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 일부 임시 파일을 삭제하는 것을 허용하는 관리용 웹 응용 프로그램의 일부입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.

...
btype = request->get_form_field( 'backuptype' )
CONCATENATE `/K 'c:\\util\\rmanDB.bat ` btype `&&c:\\util\\cleanup.bat'` INTO cmd.

CALL FUNCTION 'SXPG_COMMAND_EXECUTE_LONG'
  EXPORTING
    commandname                   = cmd_exe
    long_params                   = cmd_string
  EXCEPTIONS
    no_permission                 = 1
    command_not_found             = 2
    parameters_too_long           = 3
    security_risk                 = 4
    OTHERS                        = 5.
...

이때 문제는 사용자로부터 읽어들인 backuptype 매개 변수를 프로그램이 검증하지 않는다는 점입니다. 일반적으로 SXPG_COMMAND_EXECUTE_LONG 함수 모듈은 여러 명령을 실행하지 않지만 이 경우에는 프로그램이 먼저 CALL 'SYSTEM'에 대한 단일 호출을 사용하여 여러 명령을 실행하기 위해 cmd.exe 셸을 실행합니다. 셸을 호출하면 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.

...
MOVE 'make' to cmd.
CALL 'SYSTEM' ID 'COMMAND' FIELD cmd ID 'TAB' FIELD TABL[].
...

여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 CALL 'SYSTEM' 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 코드는 구성 파일의 입력을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.

        ...
        var fs:FileStream = new FileStream();
        fs.open(new File(String(configStream.readObject())+".txt"), FileMode.READ);
        home = String(fs.readObject(home));
        var cmd:String = home + INITCMD;
        fscommand("exec", cmd);
        ...

Example 1의 코드는 구성 파일 configStream의 내용을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 파일에서 읽은 값을 확인하지 않기 때문에 공격자가 해당 값을 제어할 수 있는 경우, 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에서 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 여러 임시 파일을 삭제하도록 설계된 관리 웹 응용 프로그램에서 온 것입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.

        ...
        var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
        var btype:String = String(params["backuptype"]);
        var cmd:String = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\"";
        fscommand("exec", cmd);
        ...

이때 문제는 사용자로부터 읽어들인 backuptype 매개 변수를 프로그램이 검증하지 않는다는 점입니다. 일반적으로 fscommand() 함수는 여러 명령을 실행하지 않지만 이 경우에는 프로그램이 먼저 fscommnd()에 대한 단일 호출을 사용하여 여러 명령을 실행하기 위해 cmd.exe 셸을 실행합니다. 셸을 호출하면 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.

        ...
        fscommand("exec", "make");
        ...

여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 fscommand() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 시스템 속성 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.

...
string val = Environment.GetEnvironmentVariable("APPHOME");
string cmd = val + INITCMD;
ProcessStartInfo startInfo = new ProcessStartInfo(cmd);
Process.Start(startInfo);
...

Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에서 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 여러 임시 파일을 삭제하도록 설계된 관리 웹 응용 프로그램에서 온 것입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.

...
string btype = BackupTypeField.Text;
string cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat"
              + btype + "&&c:\\util\\cleanup.bat\""));
Process.Start(cmd);
...

이때 문제는 프로그램이 BackupTypeField에 대해 검증을 수행하지 않는다는 점입니다. 일반적으로 Process.Start() 함수는 여러 명령을 실행하지 않지만, 이 경우에는 프로그램이 Process.Start()에 대한 단일 호출로 여러 명령을 실행하기 위해 먼저 cmd.exe 셸을 실행합니다. 셸이 호출된 후 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자에게 시스템의 암호를 업데이트할 수 있는 인터페이스에 대한 액세스를 제공하는 웹 응용 프로그램의 일부입니다. 이 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 다음에서처럼 update.exe 명령을 실행하는 것입니다.

...
Process.Start("update.exe");
...

여기서 문제는 프로그램이 절대 경로를 지정하지 않아 Process.start() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 update.exe라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 update.exe는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이런 경우, 주로 공격자가 명시적으로 실행되는 명령을 제어하는 첫 번째 시나리오가 관심의 대상이 됩니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.


2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열의 일부입니다.


3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음의 간단한 프로그램은 파일 이름을 명령줄 인수로 받아 파일의 내용을 사용자에게 표시합니다. 프로그램은 교육 중인 시스템 관리자에게 권한 있는 시스템 파일을 수정하거나 시스템을 손상시킬 수 있는 능력을 부여하지 않으면서 시스템 파일을 검사할 수 있는 학습 도구로 사용하기 위한 것이기 때문에 setuid root로 설치됩니다.

int main(char* argc, char** argv) {
	char cmd[CMD_MAX] = "/usr/bin/cat ";
	strcat(cmd, argv[1]);
	system(cmd);
}

프로그램이 root 권한으로 실행되기 때문에 system() 호출도 root 권한으로 실행됩니다. 사용자가 표준 파일 이름을 지정하는 경우 호출은 예상대로 동작합니다. 하지만 공격자가 ";rm -rf /" 형식의 문자열을 전달하면 system() 호출은 인수가 없어 cat을 실행할 수 없고 루트 파티션을 침범하여 루트 파티션의 내용을 재귀적으로 삭제합니다.

예제 2: 권한 있는 프로그램에서 발췌한 다음 코드는 환경 변수 $APPHOME을 사용하여 응용 프로그램의 설치 디렉터리를 결정한 다음 해당 디렉터리에서 초기화 스크립트를 실행합니다.

	...
	char* home=getenv("APPHOME");
	char* cmd=(char*)malloc(strlen(home)+strlen(INITCMD));
	if (cmd) {
		strcpy(cmd,home);
		strcat(cmd,INITCMD);
		execl(cmd, NULL);
	}
	...

Example 1에서처럼, 이 예제의 코드도 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 이 예제에서 공격자는 환경 변수 $APPHOME을 수정하여 INITCMD의 악성 버전이 들어 있는 다른 경로를 지정할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에 공격자는 환경 변수를 제어하여 응용 프로그램이 악성 코드를 실행하도록 만들 수 있습니다.

공격자는 환경 변수를 사용하여 프로그램이 호출하는 명령을 제어하므로 이 예제는 환경의 영향이 명시적입니다. 이번에는 공격자가 명령이 해석되는 방식을 변경할 때 어떤 일이 발생하는지 살펴 보겠습니다.

예제 3: 다음 코드는 사용자가 암호를 변경할 수 있는 웹 기반 CGI 유틸리티에서 발췌한 것입니다. NIS의 암호 업데이트 프로세스에는 /var/yp 디렉터리에서 make를 실행하는 일이 포함됩니다. 프로그램이 암호 레코드를 업데이트하기 때문에 setuid root가 설치되었습니다.

프로그램은 다음과 같이 make를 호출합니다.

system("cd /var/yp && make &> /dev/null");

앞의 예제와 달리, 이 예제의 명령은 하드코드되어 있기 때문에 공격자가 system()에 전달되는 인수를 제어할 수 없습니다. 하지만 프로그램이 make의 절대 경로를 지정하지 않고 명령을 호출하기 전에 환경 변수를 초기화하지 않기 때문에 공격자가 make라는 악성 바이너리를 가리키도록 $PATH 변수를 수정하여 셸 프롬프트에서 CGI 스크립트를 실행할 수 있습니다. 프로그램이 setuid root를 설치했으므로 공격자가 만든 make가 이제 root 권한으로 실행됩니다.

Windows에서는 또 다른 위험이 존재합니다.

예제 4:_spawn() 패밀리의 함수 중 하나를 호출하여 CreateProcess()를 호출하거나 직접 호출하는 경우에는 실행 파일 또는 경로의 공백에 주의해야 합니다.

...
LPTSTR cmdLine = _tcsdup(TEXT("C:\\Program Files\\MyApplication -L -S"));
CreateProcess(NULL, cmdLine, ...);
...

공백에 대한 CreateProcess()의 구문 분석 방식에 따라 운영 체제가 첫 번째로 실행하려는 실행 파일은 MyApplication.exe가 아니라 Program.exe가 됩니다. 따라서 공격자가 시스템에 Program.exe라고 하는 악성 응용 프로그램을 설치하면 Program Files 디렉터리를 사용하여 CreateProcess()를 잘못 호출하는 모든 프로그램에서 의도된 응용 프로그램이 아니라 이 악성 응용 프로그램이 실행됩니다.

환경(environment)은 프로그램 내에서 시스템 명령을 실행할 때 중요한 역할을 합니다. system(), exec() 및 CreateProcess()와 같은 함수는 자신을 호출하는 프로그램의 환경을 사용하므로 공격자가 호출 동작에 영향을 줄 수 있는 기회가 생깁니다.

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 코드를 사용하면 공격자는 cmd 요청 매개 변수를 통해 임의의 명령을 지정할 수 있습니다.

    ...
<cfset var="#url.cmd#">
<cfexecute name = "C:\windows\System32\cmd.exe"
    arguments = "/c #var#"
    timeout = "1"
    variable="mycmd">
</cfexecute>
    ...

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경할 수 있습니다. 즉, 공격자가 실행되는 명령을 명시적으로 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행되는 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴 보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 시스템 유틸리티의 다음 코드는 시스템 속성 APPHOME을 사용하여 유틸리티가 설치된 디렉터리를 확인한 다음 지정된 디렉터리의 상대 경로를 기준으로 하여 초기화 스크립트를 실행합니다.

	...
	final cmd = String.fromEnvironment('APPHOME');
    await Process.run(cmd);
	...

Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴 보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.


2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 코드는 사용자 컨트롤러 명령을 사용합니다.

  cmdName := request.FormValue("Command")
  c := exec.Command(cmdName)
  c.Run()

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 시스템 속성 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.

	...
	String home = System.getProperty("APPHOME");
	String cmd = home + INITCMD;
	java.lang.Runtime.getRuntime().exec(cmd);
	...

Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에서 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 여러 임시 파일을 삭제하도록 설계된 관리 웹 응용 프로그램에서 온 것입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.

...
String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\util\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);
...

이때 문제는 사용자로부터 읽어들인 backuptype 매개 변수를 프로그램이 검증하지 않는다는 점입니다. 일반적으로 Runtime.exec() 함수는 여러 명령을 실행하지 않지만 이 경우에는 프로그램이 먼저 Runtime.exec()에 대한 단일 호출을 사용하여 여러 명령을 실행하기 위해 cmd.exe 셸을 실행합니다. 셸을 호출하면 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.

...
System.Runtime.getRuntime().exec("make");
...

여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 Runtime.exec() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.

모바일 환경에서는 command injection과 같은 전형적인 취약점이 발생하지 않는다고 생각하는 사용자도 있습니다. 자기 자신을 공격하는 사용자는 없을 것이라 여기기 때문입니다. 그러나 모바일 플랫폼의 핵심 요소는 다양한 소스에서 다운로드되어 같은 장치에서 함께 실행되는 응용 프로그램이라는 점을 유념해야 합니다. 즉 금융 응용 프로그램과 맬웨어를 함께 실행할 가능성이 높으므로 프로세스 간 통신을 포함하도록 모바일 응용 프로그램의 공격 표면을 확장해야 합니다.

예제 4: 다음 코드는 Android 인텐트에서 실행할 명령을 읽습니다.

...
        String[] cmds = this.getIntent().getStringArrayExtra("commands");
	Process p = Runtime.getRuntime().exec("su");
        DataOutputStream os = new DataOutputStream(p.getOutputStream());
        for (String cmd : cmds) {
        	os.writeBytes(cmd+"\n");
        }
        os.writeBytes("exit\n");
        os.flush();
...

루팅된 장치에서 악성 응용 프로그램은 공격 대상 응용 프로그램이 수퍼 사용자 권한을 사용하여 임의의 명령을 실행하도록 강제 지정할 수 있습니다.

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.


2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 환경 변수 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.

var cp = require('child_process');
  ...
  var home = process.env('APPHOME');
  var cmd = home + INITCMD;
  child = cp.exec(cmd, function(error, stdout, stderr){
    ...
  });
  ...

Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작하도록 설계된 관리 웹 응용 프로그램의 일부입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.

var cp = require('child_process');
var http = require('http');
var url = require('url');

function listener(request, response){
  var btype = url.parse(request.url, true)['query']['backuptype'];
  if (btype !== undefined){
    cmd = "c:\\util\\rmanDB.bat" + btype;
    cp.exec(cmd, function(error, stdout, stderr){
      ...
    });
  }
  ...
}
...
http.createServer(listener).listen(8080);

이때 문제는 프로그램에서 사용자로부터 읽어들인 backuptype 매개 변수가 있는지 확인하지도 이를 검증하지도 않는다는 점입니다. 셸을 호출하면 여러 명령을 실행하도록 허용할 수 있으며, 응용 프로그램의 속성 때문에 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 따라서 공격자가 삽입하는 명령도 모두 이러한 권한으로 실행됩니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.

...
require('child_process').exec("make", function(error, stdout, stderr){
  ...
});
...

여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 child_process.exec() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 시스템 속성 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.

	...
	$home = $_ENV['APPHOME'];
	$cmd = $home . $INITCMD;
	system(cmd);
	...

Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에서 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 여러 임시 파일을 삭제하도록 설계된 관리 웹 응용 프로그램에서 온 것입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.

...
$btype = $_GET['backuptype'];
$cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " . $btype . "&&c:\\util\\cleanup.bat\"";
system(cmd);
...

이때 문제는 사용자로부터 읽어들인 backuptype 매개 변수를 프로그램이 검증하지 않는다는 점입니다. 일반적으로 Runtime.exec() 함수는 여러 명령을 실행하지 않지만 이 경우에는 프로그램이 먼저 Runtime.exec()에 대한 단일 호출을 사용하여 여러 명령을 실행하기 위해 cmd.exe 셸을 실행합니다. 셸을 호출하면 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.

...
$result = shell_exec("make");
...

여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 Runtime.exec() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 코드는 신뢰할 수 있는 데이터로 호출될 경우 공격자가 제어하는 시스템 명령을 실행하는 T-SQL 저장 프로시저를 정의합니다.

...
CREATE PROCEDURE dbo.listFiles (@path NVARCHAR(200))
AS

DECLARE @cmd NVARCHAR(500)
SET @cmd = 'dir ' + @path

exec xp_cmdshell @cmd

GO
...

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 시스템 속성 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.

	...
	home = os.getenv('APPHOME')
	cmd = home.join(INITCMD)
	os.system(cmd);
	...

Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에서 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 여러 임시 파일을 삭제하도록 설계된 관리 웹 응용 프로그램에서 온 것입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.

...
	btype = req.field('backuptype')
	cmd = "cmd.exe /K \"c:\\util\\rmanDB.bat " + btype + "&&c:\\util\\cleanup.bat\""
	os.system(cmd);
...

이때 문제는 사용자로부터 읽어들인 backuptype 매개 변수를 프로그램이 검증하지 않는다는 점입니다. 일반적으로 Runtime.exec() 함수는 여러 명령을 실행하지 않지만 이 경우에는 프로그램이 먼저 Runtime.exec()에 대한 단일 호출을 사용하여 여러 명령을 실행하기 위해 cmd.exe 셸을 실행합니다. 셸을 호출하면 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.

...
result = os.system("make");
...

여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 os.system() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.


2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 시스템 속성 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.

...
home = ENV['APPHOME']
cmd = home + INITCMD
Process.spawn(cmd)
...

Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 일부 임시 파일을 삭제하는 것을 허용하는 관리용 웹 응용 프로그램의 일부입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.

...
btype = req['backuptype']
cmd = "C:\\util\\rmanDB.bat #{btype} &&C:\\util\\cleanup.bat"
spawn(cmd)
...

이때 문제는 사용자로부터 읽어들인 backuptype 매개 변수를 프로그램이 검증하지 않는다는 점입니다. Kernel.spawn을 통해 셸이 호출된 후 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.

...
system("make")
...

여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 Kernel.system() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

여기서는, 공격자가 환경 변수를 변경하거나 악성 실행 파일을 검색 경로에 삽입하여 명령의 의미를 변경할 수 있는 두 번째 시나리오를 중점적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 공격자가 응용 프로그램의 환경을 수정합니다.

2. 응용 프로그램은 절대 경로 지정 또는 수행하는 이진 파일 확인 등의 작업을 거치지 않고 명령을 실행합니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다.

def changePassword(username: String, password: String) = Action { request =>
    ...
    s'echo "${password}" | passwd ${username} --stdin'.!
    ...
}

Command injection 취약점은 두 가지 형태로 나타납니다.

- 공격자가 프로그램이 실행하는 명령을 변경합니다. 공격자가 명시적으로 명령 부분을 제어합니다.

- 공격자가 프로그램이 실행되는 환경을 변경합니다. 공격자가 암시적으로 명령의 의미를 제어합니다.

이 경우에는 주로 공격자가 실행 명령을 제어할 수 있는 첫 번째 시나리오를 집중적으로 살펴보겠습니다. 이런 종류의 command injection 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스에서 데이터가 응용 프로그램에 입력됩니다.

2. 데이터는 응용 프로그램이 실행하는 명령을 나타내는 문자열 또는 문자열의 일부로 사용됩니다.

3. 응용 프로그램은 명령을 실행하여 공격자에게 공격자가 다른 방법으로는 얻을 수 없는 권한 또는 기능을 부여합니다.

예제 1: 다음 시스템 유틸리티 코드는 시스템 속성 APPHOME을 사용하여 코드가 설치되는 디렉터리를 결정한 다음 특정 디렉터리에서 상대 경로를 사용하여 초기화 스크립트를 실행합니다.

	...
	Dim cmd
	Dim home

	home = Environ$("AppHome")
	cmd = home & initCmd
	Shell cmd, vbNormalFocus
	...

Example 1의 코드는 시스템 속성 APPHOME을 INITCMD의 악성 버전이 들어 있는 다른 경로를 가리키도록 수정하기 때문에 공격자가 응용 프로그램에 대한 높은 권한으로 임의의 명령을 실행할 수 있습니다. 프로그램이 환경에서 읽은 값을 확인하지 않기 때문에, 공격자가 시스템 속성 APPHOME의 값을 제어할 수 있는 경우 응용 프로그램을 조작하여 악성 코드를 실행하게 하고 시스템을 제어할 수 있습니다.

예제 2: 다음 코드는 사용자가 rman 유틸리티 주위에서 배치 파일 래퍼를 사용하여 Oracle 데이터베이스의 백업을 시작한 다음 cleanup.bat 스크립트를 실행하여 여러 임시 파일을 삭제하도록 설계된 관리 웹 응용 프로그램에서 온 것입니다. 스크립트 rmanDB.bat는 수행할 백업의 유형을 지정하는 하나의 명령줄 매개 변수를 사용합니다. 데이터베이스에 대한 접근이 제한되어 있기 때문에 응용 프로그램은 권한 있는 사용자로 백업을 실행합니다.

...
btype = Request.Form("backuptype")
cmd = "cmd.exe /K " & Chr(34) & "c:\util\rmanDB.bat " & btype & "&&c:\util\cleanup.bat" & Chr(34) & ";
Shell cmd, vbNormalFocus
...

이때 문제는 사용자로부터 읽어들인 backuptype 매개 변수를 프로그램이 검증하지 않는다는 점입니다. 셸이 호출된 후 두 개의 앰퍼샌드로 구분된 여러 명령 실행이 허용됩니다. 공격자가 "&& del c:\\dbms\\*.*" 형식의 문자열을 전달하면 응용 프로그램은 프로그램에서 지정한 기타 명령과 함께 이 명령을 실행합니다. 응용 프로그램의 속성 때문에 응용 프로그램은 데이터베이스와 상호 작용하는 데 필요한 권한으로 실행됩니다. 즉, 공격자가 어떤 명령을 삽입해도 이 권한으로 실행합니다.

예제 3: 다음 코드는 사용자가 시스템의 암호를 업데이트할 수 있는 인터페이스를 제공하는 웹 응용 프로그램의 일부입니다. 특정 네트워크 환경에서 암호를 업데이트하는 프로세스의 일부는 /var/yp 디렉터리에서 make 명령을 실행하는 것입니다.

...
$result = shell_exec("make");
...

여기서 문제는 프로그램이 make의 절대 경로를 지정하지 않아 Runtime.exec() 호출을 실행하기 전에 실행 환경이 정리되지 않는다는 점입니다. 공격자가 $PATH 변수를 수정하여 make라는 악성 이진 파일을 가리키도록 하고 프로그램이 환경에서 실행되도록 하면 원하는 파일 대신 악성 이진 파일이 로드됩니다. 응용 프로그램은 그 속성 때문에 시스템 작업을 수행하는 데 필요한 권한으로 실행됩니다. 즉, 공격자의 make는 이 권한으로 실행되어 공격자에게 시스템의 완전한 제어권을 넘겨줄 수 있습니다.

XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Persistent(Stored 라고도 함) XSS의 경우 신뢰할 수 없는 소스는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소이지만, Reflected XSS의 경우에는 일반적으로 웹 요청입니다.


2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.

웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.

예제 1: 다음 ABAP 코드 세그먼트는 주어진 직원 ID를 가진 직원을 데이터베이스에 쿼리하여 해당 직원의 이름을 인쇄합니다.

...
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를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.

예제 2: 다음 ABAP 코드 세그먼트는 HTTP 요청에서 직원 ID 인 eid를 읽어 사용자에게 표시합니다.

...
eid = request->get_form_field( 'eid' ).
...
response->append_cdata( 'Employee ID: ').
response->append_cdata( eid ).
...

Example 1에서처럼 이 코드는 eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.

처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.

예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.

- Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.

- Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.

- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.

XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Persistent(Stored 라고도 함) XSS의 경우 신뢰할 수 없는 소스는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소이지만, Reflected XSS의 경우에는 일반적으로 웹 요청입니다.


2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.

웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.

예제 1: 다음 ActionScript 코드 세그먼트는 주어진 직원 ID를 가진 직원을 데이터베이스에 쿼리하여 해당 직원의 이름을 인쇄합니다.

  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를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.

예제 2: 다음 ActionScript 코드 세그먼트는 HTTP 요청에서 직원 ID 인 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 응답을 표시할 때 코드를 실행합니다.

처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.

예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.

- Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.

- Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.

- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.

XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Persistent XSS의 경우, 신뢰할 수 없는 소스는 주로 데이터베이스 쿼리의 결과이며, Reflected XSS의 경우에는 웹 요청입니다.

2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.

악성 컨텐츠는 일반적으로 JavaScript 코드의 일부이지만 HTML, Flash 또는 브라우저에서 실행할 수 있는 기타 활성 컨텐츠일 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.

예제 1: 다음 Apex 코드 세그먼트는 지정된 ID를 가진 연락처 이름을 데이터베이스에 쿼리하고 해당 직원의 이름을 반환하며, 이는 나중에 Visualforce 코드에 의해 인쇄됩니다.

...
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를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.

예제 2: 다음 Visualforce 코드 세그먼트는 HTTP 요청 매개 변수(username)를 읽고 사용자에게 표시합니다.

<script>
document.write('{!$CurrentPage.parameters.username}')
</script>

이 예제의 코드는 영숫자 텍스트만 수신하고 표시하도록 의도되었습니다. 하지만 username에 메타 문자 또는 소스 코드가 포함되어 있으면 웹 브라우저에 의해 실행됩니다.

처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.

예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 실행되는 방식은 두 가지가 있습니다.

- Example 1에서처럼 데이터베이스 또는 다른 데이터 저장소는 동적 콘텐트에 포함될 위험한 데이터를 응용 프로그램에 제공할 수 있습니다. 공격자의 관점에서 악성 콘텐트를 저장할 최적의 장소는 모든 사용자 특히 높은 권한을 가진 사용자(민감한 정보를 처리하고 중요한 작업을 수행할 가능성이 높은 사용자)가 액세스할 수 있는 장소입니다.

- Example 2에서처럼 데이터를 HTTP 요청에서 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. Reflected XSS는 공격자가 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공한 후 사용자에게 다시 적용하여 사용자의 브라우저에 의해 실행될 때 발생합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 공개적으로 게시되거나 피해자에게 직접 전자 메일로 전송되는 URL의 매개 변수로 악성 콘텐트를 포함하는 것입니다. 이러한 방식으로 생성된 URL은 공격자가 피해자를 속여 해당 URL을 방문하게 하는 많은 피싱 기법의 근간을 이룹니다. 사이트가 콘텐트를 사용자에게 다시 적용한 후, 해당 콘텐트가 실행되고 민감한 개인 정보 전달, 피해자 컴퓨터에서 권한이 없는 작업 실행 등과 같은 여러 작업을 수행할 수 있습니다.

XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Persistent(Stored 라고도 함) XSS의 경우 신뢰할 수 없는 소스는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소이지만, Reflected XSS의 경우에는 일반적으로 웹 요청입니다.


2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.

웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.

예제 1: 다음 ASP.NET 웹 폼은 지정된 직원 ID의 직원에 대한 데이터베이스를 쿼리하여 이 ID에 해당하는 이름을 인쇄합니다.

<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은 다음과 같이 정의된 폼 컨트롤입니다.

<form runat="server">
   ...
   <asp:Label id="EmployeeName" runat="server">
   ...
</form>

예제 2: 다음 ASP.NET 코드 세그먼트는 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를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.

예제 3: 다음 ASP.NET 웹 폼은 HTTP 요청에서 직원 ID 번호를 읽어 사용자에게 표시합니다.

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>

여기서 Login 및 EmployeeID는 다음과 같이 정의된 폼 컨트롤입니다.

<form runat="server">
   <asp:TextBox runat="server" id="Login"/>
   ...
   <asp:Label runat="server" id="EmployeeID"/>
</form>

예제 4: 다음 ASP.NET 코드 세그먼트는 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 응답을 표시할 때 코드를 실행합니다.

처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 링크를 클릭하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.

예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.

- Example 1 및 Example 2에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.

- Example 3 및 Example 4에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.

- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.

많은 최신 웹 프레임워크는 사용자 입력의 검증을 수행하기 위한 메커니즘을 제공합니다(ASP.NET Request Validation 및 WCF 포함). 확인되지 않은 입력의 소스를 강조하기 위해, Fortify 보안 코딩 규칙 팩은 악용 가능성을 낮추고 프레임워크 검증 메커니즘이 사용 중일 때마다 지원하는 증거에 포인터를 제공하여 Fortify Static Code Analyzer에서 보고한 문제의 우선 순위를 동적으로 재지정합니다. ASP.NET Request Validation으로 검증이 명시적으로 비활성화된 경우에 대한 증거도 제공합니다. 이 기능을 Context-Sensitive Ranking(컨텍스트 감지 순위)이라고 부릅니다. Fortify 사용자의 감사 프로세스를 지원하기 위해, Fortify Software Security Research Group은 입력 소스에 적용된 검증 메커니즘에 따라 문제를 폴더로 그룹화하는 데이터 유효성 프로젝트 템플릿을 사용 가능하게 만듭니다.

XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Persistent(Stored 라고도 함) XSS의 경우 신뢰할 수 없는 소스는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소이지만, Reflected XSS의 경우에는 일반적으로 웹 요청입니다.


2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.

웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.

예제 1: 다음 CFML 코드 세그먼트는 주어진 직원 ID를 가진 직원을 데이터베이스에 쿼리하여 해당 직원의 이름을 인쇄합니다.

 
<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를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.

예제 2: 다음 CFML 코드 세그먼트는 웹 폼에서 직원 ID 인 eid를 읽어 사용자에게 표시합니다.

<cfoutput>
Employee ID: #Form.eid#
</cfoutput>

Example 1에서처럼 이 코드는 Form.eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. Form.eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.

처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.

예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.

- Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.

- Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.

- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.

XSS(Cross-Site Scripting) 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Reflected XSS의 경우 신뢰할 수 없는 소스는 일반적으로 웹 요청이지만, Persisted(Stored 라고도 함) XSS의 경우에는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소입니다.

2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.

웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.


예제 1: 다음 Ruby 코드 세그먼트는 HTTP 요청에서 사용자 이름인 user를 읽어 사용자에게 표시합니다.

func someHandler(w http.ResponseWriter, r *http.Request){
  r.parseForm()
  user := r.FormValue("user")
  ...
  fmt.Fprintln(w, "Username is: ", user)
}

다음 예제의 코드는 user에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. user가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.

처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.

예제 2: 다음 Go 코드 세그먼트는 주어진 ID를 가진 직원을 데이터베이스에 쿼리하여 해당 직원의 이름을 인쇄합니다.

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를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.

예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.

- Example 1에서 볼 수 있듯이 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 반영합니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.

- Example 2에서 볼 수 있듯이 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.

- 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어들여 데이터가 동적 콘텐트에 포함됩니다.

XSS(Cross-site scripting) 취약점은 다음 경우에 발생합니다.

1. 신뢰할 수 없는 소스를 통해 데이터가 웹 응용 프로그램에 입력됩니다. Persistent(Stored 라고도 함) XSS의 경우 신뢰할 수 없는 소스는 일반적으로 데이터베이스 또는 다른 백엔드 데이터 저장소이지만, Reflected XSS의 경우에는 일반적으로 웹 요청입니다.


2. 데이터는 검증 없이 웹 사용자에게 전달된 동적 콘텐트에 포함됩니다.

웹 브라우저에 전달되는 악성 콘텐트는 흔히 JavaScript 세그먼트의 형태를 취하지만 HTML, Flash 또는 기타 브라우저가 실행하는 다른 모든 유형의 코드를 포함할 수도 있습니다. XSS 기반의 공격은 거의 무제한으로 다양하지만, 흔히 쿠키 또는 기타 세션 정보와 같은 개인 데이터를 공격자에게 전송하여 피해자를 공격자가 제어하는 웹 콘텐트에 리디렉션하거나 피해 사이트로 위장하고 사용자 컴퓨터에 기타 악의적인 작업을 수행하는 것이 공통적인 수법입니다.

예제 1: 다음 JSP 코드 세그먼트는 지정된 직원 ID의 직원에 대한 데이터베이스를 쿼리하여 해당 직원의 이름을 인쇄합니다.

<%...
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를 삽입하면 이후에 방명록 페이지를 방문하는 방문자는 모두 악성 코드를 실행하게 됩니다.

예제 2: 다음 JSP 코드 세그먼트는 HTTP 요청에서 직원 ID인 eid를 읽어 사용자에게 표시합니다.

<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>

Example 1에서처럼 이 코드는 eid에 표준 영숫자 텍스트만 있으면 올바로 동작합니다. eid가 메타 문자나 소스 코드가 포함된 값을 갖는 경우, 웹 브라우저가 HTTP 응답을 표시할 때 코드를 실행합니다.

처음에는 이것이 큰 취약점으로 보이지 않을 수도 있습니다. 결국 누군가 URL을 입력하여 자신의 컴퓨터에서 악성 코드가 실행되게 하는 이유는 무엇입니까? 정말 위험한 일은 공격자가 악성 URL을 만든 다음 전자 메일 또는 사회 공학 속임수를 사용하여 피해자가 URL의 링크를 방문하도록 만드는 것입니다. 피해자가 링크를 클릭하면 모르는 사이에 취약한 웹 응용 프로그램을 통해 해로운 내용을 본인의 컴퓨터로 전달하게 됩니다. 취약한 웹 응용 프로그램을 익스플로이트하는 메커니즘을 Reflected XSS 라고 합니다.

모바일 환경에서는 Cross-Site Scripting과 같은 전형적인 웹 응용 프로그램 취약성이 발생하지 않는다고 생각하는 사용자도 있습니다. 자기 자신을 공격하는 사용자는 없을 것이라 여기기 때문입니다. 그러나 모바일 플랫폼의 핵심 요소는 다양한 소스에서 다운로드되어 같은 장치에서 함께 실행되는 응용 프로그램이라는 점을 유념해야 합니다. 즉 금융 응용 프로그램과 맬웨어를 함께 실행할 가능성이 높으므로 프로세스 간 통신을 포함하도록 모바일 응용 프로그램의 공격 표면을 확장해야 합니다.

예제 3: 다음 코드는 Android의 WebView에서 JavaScript를 활성화(기본적으로 JavaScript는 비활성화됨)하고 Android 인텐트에서 받은 값을 기준으로 페이지를 로드합니다.

...
        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 내에 있는 웹 페이지의 컨텍스트에서 실행됩니다.

예제에서처럼, XSS 취약점은 HTTP 응답에 확인되지 않은 데이터가 포함된 코드 때문에 발생합니다. XSS 공격이 피해자에게 가해지는 방식은 세 가지가 있습니다.

- Example 1에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Persistent XSS 익스플로이트는 공격자가 위험한 콘텐트를 데이터 저장소에 삽입하고 이 콘텐트를 나중에 읽어 들여 동적 콘텐트에 포함시킬 때 발생합니다. 공격자의 관점에서 악성 콘텐트를 삽입할 최적의 장소는 많은 사용자나 특히 관련 사용자에게 표시되는 장소입니다. 일반적으로 관련 사용자는 응용 프로그램에 권한을 높이거나 공격자가 원하는 민감한 데이터와 상호 작용합니다. 이런 사용자가 악성 콘텐트를 실행하면 공격자는 사용자 대신 권한 있는 작업을 실행하거나 사용자 소유의 민감한 데이터에 접근할 수 있습니다.

- Example 2에서처럼 데이터를 HTTP 요청에서 직접 읽어 들여 HTTP 응답에 다시 적용하는 것입니다. 적용된 XSS 익스플로이트는 공격자가 사용자로 하여금 위험한 콘텐트를 취약한 웹 응용 프로그램에 제공하도록 만드는 것입니다. 이 위험한 콘텐트는 다시 사용자에게 돌아가고 웹 브라우저가 이를 실행합니다. 악성 콘텐트를 제공하는 가장 일반적인 메커니즘은 콘텐트를 공용으로 게시하거나 피해자에게 직접 전자 메일로 보내지는 URL의 매개 변수로 포함하는 것입니다. 이런 식으로 생성된 URL은 많은 공격자가 피해자를 속여 피해 사이트를 참조하는 URL을 방문하게 하는 피싱 기법의 근간을 이룹니다. 사이트가 공격자의 콘텐트를 사용자에게 보내면, 콘텐트가 실행되고 세션 정보가 들어있는 쿠키 등의 개인 정보가 사용자의 컴퓨터에서 공격자에게 전송되거나 다른 악의적인 작업이 수행됩니다.

- Example 3과 같이 응용 프로그램 외부의 소스에서 데이터베이스 또는 기타 데이터 저장소에 위험한 데이터를 저장하고 위험한 데이터를 응용 프로그램이 신뢰할 수 있는 데이터로 읽어 들여 데이터가 동적 콘텐트에 포함됩니다.

많은 최신 웹 프레임워크는 사용자 입력의 검증을 수행하기 위한 메커니즘을 제공합니다(Struts 및 Struts 2 포함). 확인되지 않은 입력의 소스를 강조하기 위해, Fortify 보안 코딩 규칙 팩은 악용 가능성을 낮추고 프레임워크 검증 메커니즘이 사용 중일 때마다 지원하는 증거에 포인터를 제공하여 Fortify Static Code Analyzer에서 보고한 문제의 우선 순위를 동적으로 재지정합니다. 이 기능을 Context-Sensitive Ranking(컨텍스트 감지 순위)이라고 부릅니다. Fortify 사용자의 감사 프로세스를 지원하기 위해, Fortify Software Security Research Group은 입력 소스에 적용된 검증 메커니즘에 따라 문제를 폴더로 그룹화하는 데이터 유효성 프로젝트 템플릿을 사용 가능하게 만듭니다.