SQL injection 오류는 다음 경우에 발생합니다.

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

이런 경우, Fortify Static Code Analyzer는 데이터 소스를 신뢰할 수 있는 것으로 판단하지 않습니다.

2. 데이터를 사용하여 SQL 쿼리를 동적으로 생성합니다.

예제 1: 다음 코드는 지정된 이름과 일치하는 항목을 검색하는 SQL 쿼리를 동적으로 생성하고 실행합니다. 쿼리는 표시되는 항목을 항목 소유자가 현재 인증된 사용자의 이름과 일치하는 항목으로 제한합니다.

...
        String userName = ctx.getAuthenticatedUserName();
        String itemName = request.getParameter("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        ResultSet rs = stmt.execute(query);
...

쿼리는 다음 코드를 실행하려고 합니다.

        SELECT * FROM items
        WHERE owner = <userName>
        AND itemname = <itemName>;

하지만 상수인 기본 쿼리 문자열과 사용자 입력 문자열을 연결하여 쿼리를 동적으로 생성하기 때문에, 쿼리는 itemName에 작은따옴표가 들어 있지 않은 경우에만 정확하게 동작합니다. 사용자 이름이 wiley인 공격자가 itemName에 문자열 "name' OR 'a'='a"를 입력하면 쿼리는 다음과 같이 생성됩니다.

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name' OR 'a'='a';

OR 'a'='a' 조건을 추가하면 where 절이 항상 true로 평가하기 때문에 쿼리는 훨씬 간단한 다음 쿼리와 논리적으로 동일하게 됩니다.

        SELECT * FROM items;

공격자는 이렇게 쿼리를 단순화하여 쿼리가 인증된 사용자가 소유한 항목만 반환해야 한다는 요구 사항을 무시할 수 있습니다. 이제 쿼리는 지정된 소유자와 관계없이 items 테이블에 저장된 모든 항목을 반환합니다.

예제 2: 이 예제는 Example 1에서 생성하여 수행한 쿼리에 또 다른 악성 값이 전달될 때의 결과를 검토합니다. 사용자 이름이 wiley인 공격자가 itemName에 문자열 "name'; DELETE FROM items; --"를 입력하면 쿼리는 다음과 같은 두 개의 쿼리가 됩니다.

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name';

        DELETE FROM items;

        --'

Microsoft(R) SQL Server 2000을 포함한 많은 데이터베이스 서버에서 여러 SQL 문을 세미콜론으로 구분하여 한꺼번에 실행하는 것을 허용합니다. 이 공격 문자열은 세미콜론으로 구분한 문에 대한 일괄 실행을 허용하지 않는 Oracle 및 기타 데이터베이스 서버에서는 오류를 일으키지만 일괄 실행을 허용하는 데이터베이스에서는 공격자가 이런 종류의 공격으로 데이터베이스에 대해 임의의 명령을 실행할 수 있습니다.

마지막의 하이픈 쌍(--)을 보겠습니다. 이는 대부분의 데이터베이스 서버에서 해당 문에 대한 나머지 부분을 주석으로 처리하여 실행하지 말라는 의미로 해석됩니다[4]. 이 경우, 이 주석 문자는 수정된 쿼리에서 마지막의 작은따옴표 한쪽을 제거하는 역할을 합니다. 주석을 이런 식으로 사용할 수 없는 데이터베이스에서도 Example 1에서 사용된 것과 유사한 속임수를 사용하면 대부분의 공격이 효과를 거둘 수 있습니다. 공격자가 문자열 "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a"를 입력하여 다음 세 가지 유효한 문을 만드는 경우입니다.

        SELECT * FROM items
        WHERE owner = 'wiley'
        AND itemname = 'name';

        DELETE FROM items;

        SELECT * FROM items WHERE 'a'='a';

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

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

...
        PasswordAuthentication pa = authenticator.getPasswordAuthentication();
        String userName = pa.getUserName();
        String itemName = this.getIntent().getExtras().getString("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, null);
...

SQL Injection 공격을 방지하는 한 가지 기존의 접근 방식은 공격을 입력값 검증 문제로 처리하고 안전한 값 목록(허용 목록)의 문자만 받거나 악의적일 가능성이 있는 값 목록(거부 목록)을 식별하여 이스케이프 처리하는 것입니다. 허용 목록 검사는 엄격한 입력값 검증 규칙을 이행하는 매우 효율적인 수단이 되기도 하지만, 매개 변수가 있는 SQL 문은 유지 관리가 쉽고 보다 강력한 보안을 제공할 수 있습니다. 대부분의 경우 거부 목록 구현은 SQL Injection 공격 방지의 효과를 떨어뜨리는 허점이 아주 많습니다. 예를 들어, 공격자는 다음과 같이 할 수 있습니다.

- 따옴표로 묶지 않은 필드를 노립니다.
- 이스케이프 처리된 메타 문자를 사용할 필요가 없는 방법을 찾습니다.
- 저장 프로시저(Stored procedure)를 사용하여 삽입된 메타 문자를 숨깁니다.

SQL 쿼리에 입력할 때 수동으로 문자를 이스케이프 처리하는 방법도 있지만 이것으로 SQL injection 공격으로부터 응용 프로그램을 보호할 수는 없습니다.

SQL injection 공격을 다루는 데 주로 제시되는 다른 솔루션은 저장 프로시저(stored procedure)를 사용하는 것입니다. 저장 프로시저(Stored procedure)는 일부 유형의 SQL injection 공격은 막을 수 있지만 다른 많은 유형은 막지 못합니다. 저장 프로시저(Stored procedure)는 일반적으로 매개 변수에 전달되는 SQL 문의 유형을 제한하여 SQL injection 공격을 막습니다. 하지만 이 제약을 피할 수 있는 많은 방법이 있어 수많은 비정상적인 문을 저장 프로시저(Stored procedure)에 전달할 수 있습니다. 되풀이하지만, 저장 프로시저(Stored procedure)는 일부 익스플로이트는 막을 수 있지만 응용 프로그램을 SQL injection 공격에 대해 안전하게 보호할 수는 없습니다.

mysql_real_escape_string() 같은 인코딩 함수를 사용하면 일부 SQL Injection 취약점이 방지되지만 전부 방지되지는 않습니다. 이러한 인코딩 함수를 사용하는 것은 약한 거부 목록을 사용하여 SQL Injection을 차단하는 것과 동일하며 공격자가 문의 의미를 수정하거나 임의의 SQL 명령을 실행하는 것이 가능할 수 있습니다. 동적으로 해석되는 코드의 지정된 섹션 내에서 입력이 표시되는 위치를 정적으로 확인하는 것이 항상 가능하지는 않으므로 Fortify Secure Coding Rulepacks는 해당 컨텍스트 내에서 검증을 통해 충분히 SQL Injection을 차단할 수 있는 경우에도 검증된 동적 SQL 데이터를 "SQL Injection: Poor Validation" 이슈로 표시할 수 있습니다.

SQL Injection 오류는 다음 경우에 발생합니다.

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



2. 데이터를 사용하여 SQL 쿼리를 동적으로 생성합니다.

예제 1: 다음 예제는 데이터베이스의 구성으로 인해 변경될 수 있는 mysqli_real_escape_string()의 동작을 보여줍니다. SQL 모드가 "NO_BACKSLASH_ESCAPES"로 설정된 경우 백슬래시 문자가 이스케이프 문자[5]가 아닌 일반 문자로 처리됩니다. mysqli_real_escape_string()은 이를 고려하므로 다음 쿼리는 SQL Injection에 취약해집니다. 데이터베이스 구성으로 인해 "가 더 이상 \"로 이스케이프 처리되지 않기 때문입니다.

  mysqli_query($mysqli, 'SET SQL_MODE="NO_BACKSLASH_ESCAPES"');
  ...
  $userName = mysqli_real_escape_string($mysqli, $_POST['userName']);
  $pass = mysqli_real_escape_string($mysqli, $_POST['pass']);
  $query = 'SELECT * FROM users WHERE userName="' . $userName . '"AND pass="' . $pass. '";';
  $result = mysqli_query($mysqli, $query);
  ...

공격자가 password 필드를 비워 두고 " OR 1=1;-- 을 userName으로 입력하면 따옴표가 이스케이프 처리되지 않고 다음과 같은 쿼리가 생성됩니다.

  SELECT * FROM users
  WHERE userName = ""
  OR 1=1;
  -- "AND pass="";

OR 1=1로 인해 where 절이 항상 true로 평가되고 하이픈 두 개로 인해 나머지 문이 주석으로 처리되므로 이 쿼리는 훨씬 더 단순한 쿼리와 논리적으로 동일해집니다.

  SELECT * FROM users;

SQL Injection 공격을 방지하는 한 가지 기존의 접근 방식은 공격을 입력값 검증 문제로 처리하고 안전한 값 목록(허용 목록)의 문자만 받거나 악의적일 가능성이 있는 값 목록(거부 목록)을 식별하여 이스케이프 처리하는 것입니다. 허용 목록 검사는 엄격한 입력값 검증 규칙을 이행하는 매우 효율적인 수단이 되기도 하지만, 매개 변수가 있는 SQL 문은 유지 관리가 쉽고 보다 강력한 보안을 제공할 수 있습니다. 대부분의 경우 거부 목록 구현은 SQL Injection 공격 방지의 효과를 떨어뜨리는 허점이 아주 많습니다. 예를 들어, 공격자는 다음과 같이 할 수 있습니다.

- 따옴표로 묶지 않은 필드를 노립니다.
- 이스케이프 처리된 메타 문자를 사용할 필요가 없는 방법을 찾습니다.
- 저장 프로시저(Stored procedure)를 사용하여 삽입된 메타 문자를 숨깁니다.

SQL 쿼리에 입력할 때 수동으로 문자를 이스케이프 처리하는 방법도 있지만 이것으로 SQL Injection 공격으로부터 응용 프로그램을 보호할 수는 없습니다.

SQL Injection 공격을 다루는 데 주로 제시되는 다른 솔루션은 저장 프로시저(Stored procedure)를 사용하는 것입니다. 저장 프로시저(Stored procedure)는 일부 유형의 SQL Injection 공격은 막을 수 있지만 다른 많은 유형은 막지 못합니다. 저장 프로시저(Stored procedure)는 일반적으로 매개 변수에 전달되는 SQL 문의 유형을 제한하여 SQL Injection 공격을 막습니다. 하지만 이 제약을 피할 수 있는 많은 방법이 있어 수많은 비정상적인 문을 저장 프로시저(Stored procedure)에 전달할 수 있습니다. 다시 말해, 저장 프로시저(Stored procedure)는 일부 익스플로이트는 막을 수 있지만 응용 프로그램을 SQL Injection 공격에 대해 안전하게 보호할 수는 없습니다.

SubSonic과 관련된 SQL injection 오류는 다음 경우에 발생합니다.

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

2. 데이터를 사용하여 쿼리를 동적으로 생성합니다.
예제 1: 다음 코드는 지정된 이름과 일치하는 항목을 검색하는 SubSonic 쿼리를 동적으로 생성하고 실행합니다. 쿼리는 현재 인증된 사용자의 이름과 owner가 일치하는 항목만 표시하도록 제한합니다.

...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";

IDataReader responseReader = new InlineQuery().ExecuteReader(query);
...

쿼리는 다음 코드를 실행하려고 합니다.

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

하지만 상수인 기본 쿼리 문자열과 사용자 입력 문자열을 연결하여 쿼리를 동적으로 생성하기 때문에, 쿼리는 itemName에 작은따옴표가 들어 있지 않은 경우에만 정확하게 동작합니다. 사용자 이름이 wiley인 공격자가 itemName에 문자열 "name' OR 'a'='a"를 입력하면 쿼리는 다음과 같이 생성됩니다.

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

OR 'a'='a' 조건을 추가하면 where 절이 항상 true로 평가하기 때문에 쿼리는 훨씬 간단한 다음 쿼리와 논리적으로 동일하게 됩니다.

	SELECT * FROM items;

공격자는 이렇게 쿼리를 단순화하여 쿼리가 인증된 사용자가 소유한 항목만 반환해야 한다는 요구 사항을 무시할 수 있습니다. 이제 쿼리는 지정된 소유자와 관계없이 items 테이블에 저장된 모든 항목을 반환합니다.

예제 2: 이 예제는 Example 1에서 생성하여 수행한 쿼리에 또 다른 악성 값이 전달될 때의 결과를 검토합니다. 사용자 이름이 wiley인 공격자가 itemName에 문자열 "name'); DELETE FROM items; --"를 입력하면 쿼리는 다음과 같은 두 개의 쿼리가 됩니다.

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

Microsoft(R) SQL Server 2000을 포함한 많은 데이터베이스 서버에서 여러 SQL 문을 세미콜론으로 구분하여 한꺼번에 실행하는 것을 허용합니다. 이 공격 문자열은 세미콜론으로 구분한 문에 대한 일괄 실행을 허용하지 않는 Oracle 및 기타 데이터베이스 서버에서는 오류를 일으키지만 일괄 실행을 허용하는 데이터베이스에서는 공격자가 이런 종류의 공격으로 데이터베이스에 대해 임의의 명령을 실행할 수 있습니다.

마지막의 하이픈 쌍(--)을 보겠습니다. 이는 대부분의 데이터베이스 서버에서 해당 문에 대한 나머지 부분을 주석으로 처리하여 실행하지 말라는 의미로 해석됩니다[4]. 이 경우, 이 주석 문자는 수정된 쿼리에서 마지막의 작은따옴표 한쪽을 제거하는 역할을 합니다. 주석을 이런 식으로 사용할 수 없는 데이터베이스에서도 Example 1에서 본 것과 유사한 속임수를 사용하면 대부분의 공격이 효과를 거둘 수 있습니다. 공격자가 문자열 "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a"를 입력하여 다음 세 가지 유효한 문을 만드는 경우입니다.

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

SubSonic injection 공격을 방지하는 한 가지 기존의 접근 방식은 공격을 입력값 검증 문제로 처리하고 안전한 값 목록(허용 목록)의 문자만 받거나 악의적일 가능성이 있는 값 목록(거부 목록)을 식별하여 이스케이프 처리하는 것입니다. 허용 목록 검사가 엄격한 입력값 검증 규칙을 이행하는 매우 효율적인 수단이 되기도 하지만, 매개 변수가 있는 SubSonic 문은 유지 관리가 쉽고 보다 강력한 보안을 제공할 수 있습니다. 대부분의 경우 거부 목록 구현은 SubSonic SQL injection 공격 방지의 효과를 떨어뜨리는 허점이 아주 많습니다. 예를 들어, 공격자는 다음과 같이 할 수 있습니다.

- 따옴표로 묶지 않은 필드를 노립니다.
- 이스케이프 처리된 메타 문자를 사용할 필요가 없는 방법을 찾습니다.
- 저장 프로시저(Stored procedure)를 사용하여 삽입된 메타 문자를 숨깁니다.

SubSonic 쿼리에 입력할 때 수동으로 문자를 이스케이프 처리하는 방법도 있지만 이것으로 SubSonic SQL injection 공격으로부터 응용 프로그램을 보호할 수는 없습니다.

SubSonic injection 공격을 다루는 데 주로 제시되는 다른 해결책은 저장 프로시저(stored procedure)를 사용하는 것입니다. 저장 프로시저(Stored procedure)는 일부 유형의 SubSonic injection 공격은 막을 수 있지만 다른 많은 형식은 막지 못합니다. 저장 프로시저(Stored procedure)는 일반적으로 매개 변수에 전달되는 해당 문의 형식을 제한하여 SubSonic SQL injection 공격을 막습니다. 하지만 이 제약을 피할 수 있는 많은 방법이 있어 수많은 비정상적인 문을 저장 프로시저(Stored procedure)에 전달할 수 있습니다. 되풀이하지만, 저장 프로시저(Stored procedure)는 일부 익스플로이트는 막을 수 있지만 응용 프로그램을 SubSonic injection 공격에 대해 안전하게 보호할 수는 없습니다.

민감한 정보가 포함되어 있거나 원격 관리 패널 같은 권한이 지정된 기능이 포함되어 있는 서버는 액세스를 위한 인증을 요구해야 합니다. 그렇지 않으면 공격자가 간단히 일반 사용자 이름을 추측하는 것만으로 민감한 정보를 훔치거나 대상 호스트를 제어할 수 있습니다.

클라이언트는 NoneAuth 인증 메서드를 사용하여 사용 가능한 인증 메서드를 결정합니다.

예제 1: 다음 Paramiko 코드는 "없음" 인증 요청을 사용하여 서버 인증을 시도합니다.

    client = SSHClient()
    client.connect(host, port, auth_strategy=NoneAuth("user"))

String termination error는 다음 경우에 발생합니다.

1. 데이터가 출력을 null로 끝내지 않는 함수를 통해 프로그램에 입력됩니다.

2. 입력을 null로 끝내야 하는 함수에 데이터를 전달합니다.
예제 1: 다음 코드는 cfgfile에서 읽어 strcpy()를 사용하여 입력을 inputbuf에 복사합니다. 코드는 inputbuf에 항상 null 종결자가 있다고 잘못 가정합니다.

#define MAXLEN 1024
...
char *pathbuf[MAXLEN];
...
read(cfgfile,inputbuf,MAXLEN); //does not null-terminate
strcpy(pathbuf,inputbuf); //requires null-terminated input
...

Example 1의 코드는 cfgfile에서 읽은 데이터가 예상대로 디스크에서 null로 끝나면 정확하게 동작합니다. 하지만 공격자가 이 입력을 예상하는 null 문자를 포함하지 않도록 수정할 수 있다면 strcpy() 호출은 임의의 null 문자를 만날 때까지 계속 메모리에서 복사합니다. 이는 대상 버퍼에 오버플로를 일으킬 가능성이 크며, 공격자가 inputbuf 바로 다음의 메모리 내용을 제어할 수 있게 되면 응용 프로그램이 buffer overflow 공격에 취약해질 수 있습니다.

예제 2: 다음 코드에서 readlink()는 버퍼 path에 저장된 심볼 링크의 이름을 확장하여 심볼 링크에서 참조하는 파일의 절대 경로가 버퍼 buf에 포함되도록 합니다. 그런 다음, 결과 값의 길이를 strlen()을 사용하여 계산합니다.

...
char buf[MAXPATH];
...
readlink(path, buf, MAXPATH);
int length = strlen(buf);
...

Example 2의 코드는 readlink()를 통해 buf로 읽은 값이 null로 끝나지 않기 때문에 올바로 동작하지 않습니다. 테스트에서 buf 및 버퍼 바로 다음 메모리의 사용되지 않는 내용이 null일 수 있기 때문에 이런 취약점을 발견하지 못할 수 있으므로 strlen()이 올바로 동작하는 것처럼 보입니다. 하지만, 실제 상황에서는 strlen()이 스택에서 임의의 null 문자를 발견할 때까지 계속 메모리를 탐색하기 때문에 결국 buf의 크기보다 훨씬 큰 length 값이 발생하고 이후에 이 값을 사용하면 buffer overflow가 발생할 수 있습니다.

예제 3: 다음 코드는 snprintf()를 사용하여 사용자 입력 문자열을 복사하고 여러 출력 문자열에 넣습니다. sprintf()와 비교하여 추가 가드레일, 특히 최대 출력 크기의 지정을 제공함에도 불구하고 snprintf() 함수는 지정된 출력 크기가 예상 입력보다 큰 경우 여전히 문자열 종료 오류가 발생할 수 있습니다. 문자열 종료 오류는 메모리 누수 또는 buffer overflow와 같은 다운스트림 문제로 이어질 수 있습니다.

...
char no_null_term[5] = getUserInput();

char output_1[20];
snprintf(output_1, 20, "%s", no_null_term);

char output_2[20];
snprintf(output_2, 20, "%s", no_null_term);


printf("%s\n", output_1);
printf("%s\n", output_2);
...

Example 3의 코드는 메모리 누수를 보여줍니다. output_2가 no_null_term으로 채워진 경우 snprintf()는 null 문자가 나타나거나 지정된 크기 제한에 도달할 때까지 no_null_term 위치에서 읽어야 합니다. no_null_term에서 종료 문자가 없으므로 snprintf는 결국 snprintf()의 첫 번째 호출에서 제공되는 null로 종료되는 문자에 도달하는 output_1의 데이터를 계속해서 읽습니다. 메모리 누수는 output_2의 printf()에서 보여 주며, 여기에는 no_null_term의 문자 시퀀스가 두 번 포함됩니다.

전통적으로 문자열은 null 문자로 끝나는 데이터를 포함한 메모리의 한 부분으로 표현합니다. 이전 문자열 처리 메서드는 자주 이 null 문자를 사용하여 문자열 길이를 결정합니다. null 종결자가 없는 버퍼가 이 함수 중 하나로 전달될 경우, 해당 함수는 버퍼의 끝을 지나 계속 읽습니다.

악의적인 사용자는 보통 예기치 못한 크기나 내용의 데이터를 응용 프로그램에 삽입하여 이런 유형의 취약점을 익스플로이트합니다. 악성 입력을 프로그램 입력으로 직접적으로 제공하거나 구성 파일과 같은 응용 프로그램 리소스를 수정하여 간접적으로 제공합니다. 공격자가 응용 프로그램이 버퍼 범위를 넘어서 읽도록 만드는 경우 공격자는 그 결과로 발생하는 buffer overflow를 이용하여 시스템에 임의의 코드를 삽입하여 실행할 수도 있습니다.

Apache Struts 2.x에는 개발자가 Actions 코드에 관련 런타임 정보가 포함된 맵을 쉽게 삽입할 수 있는 새로운 Aware 인터페이스가 포함되어 있습니다. 이러한 인터페이스로는 org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware 및 org.apache.struts2.interceptor.RequestAware가 있습니다. 이러한 데이터 맵을 자신이 개발한 Actions 코드에 삽입하려는 개발자는 인터페이스에 지정된 setter를 구현해야 합니다(예: SessionAware 인터페이스의 경우 setSession).

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

반면 Struts 2.x는 Action에 정의된 공용 접근자를 통해 사용자로부터 제공되는 요청 데이터를 Action의 속성에 자동으로 바인딩합니다. Aware 인터페이스를 사용하려면 Aware 인터페이스에 정의된 공용 setter를 구현해야 하며, 이 setter 도 Aware 인터페이스 setter 이름과 일치하는 모든 요청 매개 변수에 자동으로 바인딩됩니다. 이 동작으로 인해 SessionAware, RequestAware, ApplicationAware 인터페이스에서 보여 준 것처럼 원격 공격자가 영향을 받는 인터페이스를 구현한 응용 프로그램에 조작된 매개 변수를 제공하여 런타임 데이터 값을 수정할 수 있습니다.

다음 URL을 통해 공격자가 세션 맵에서 "roles" 속성을 재정의할 수 있습니다. 이를 통해 공격자가 관리자가 될 수도 있습니다.

http://server/VulnerableAction?session.roles=admin


이러한 인터페이스에서는 setter 접근자 구현만 요구하지만 해당하는 getter 도 구현한 경우 이러한 맵 컬렉션 변경 사항은 현재 요청 범위에만 적용되는 것이 아니라 세션 범위 내에서 지속됩니다.

Struts 2에는 Action에서 execute() 이외의 메서드를 노출할 수 있도록 하는 "동적 메서드 호출"이라는 기능이 도입되었습니다. "동적 메서드 호출"이 활성화된 경우 Action URL에 !(느낌표) 문자 또는 method: 접두사를 사용하여 Action의 모든 public 메서드를 호출할 수 있습니다. 이 기능을 알지 못하는 개발자는 내부 비즈니스 로직을 공격자에게 실수로 노출할 수 있습니다.

예를 들어 인수를 사용하지 않는 getUserPassword()라는 public 메서드가 포함된 Action에서 "동적 메서드 호출" 기능을 비활성화하지 못하면 공격자가 다음 URL을 방문하여 해당 기능을 이용할 수 있습니다. http://server/app/recoverpassword!getPassword.action

Apache Struts 2.x에는 개발자가 Actions 코드에 관련 런타임 정보가 포함된 맵을 쉽게 삽입할 수 있는 새로운 Aware 인터페이스가 포함되어 있습니다. 이러한 인터페이스로는 org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware 및 org.apache.struts2.interceptor.RequestAware가 있습니다. 이러한 데이터 맵을 자신이 개발한 Actions 코드에 삽입하려는 개발자는 인터페이스에 지정된 setter를 구현해야 합니다(예: SessionAware 인터페이스의 경우 setSession).

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

반면 Struts 2.x는 Action에 정의된 공용 접근자를 통해 사용자로부터 제공되는 요청 데이터를 Action의 속성에 자동으로 바인딩합니다. Aware 인터페이스를 사용하려면 Aware 인터페이스에 정의된 공용 setter를 구현해야 하며, 이 setter 도 Aware 인터페이스 setter 이름과 일치하는 모든 요청 매개 변수에 자동으로 바인딩됩니다. 이 동작으로 인해 SessionAware, RequestAware, ApplicationAware 인터페이스에서 보여 준 것처럼 원격 공격자가 영향을 받는 인터페이스를 구현한 응용 프로그램에 조작된 매개 변수를 제공하여 런타임 데이터 값을 수정할 수 있습니다.

다음 URL을 통해 공격자가 세션 맵에서 "roles" 속성을 재정의할 수 있습니다. 이를 통해 공격자가 관리자가 될 수도 있습니다.

http://server/VulnerableAction?session.roles=admin


이러한 인터페이스에서는 setter 접근자 구현만 요구하지만 해당하는 getter 도 구현한 경우 이러한 맵 컬렉션 변경 사항은 현재 요청 범위에만 적용되는 것이 아니라 세션 범위 내에서 지속됩니다.

Apache Struts 2.x에는 개발자가 Actions 코드에 관련 런타임 정보가 포함된 맵을 쉽게 삽입할 수 있는 새로운 Aware 인터페이스가 포함되어 있습니다. 이러한 인터페이스로는 org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware 및 org.apache.struts2.interceptor.RequestAware가 있습니다. 이러한 데이터 맵을 자신이 개발한 Actions 코드에 삽입하려는 개발자는 인터페이스에 지정된 setter를 구현해야 합니다(예: SessionAware 인터페이스의 경우 setSession).

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

반면 Struts 2.x는 Action에 정의된 공용 접근자를 통해 사용자로부터 제공되는 요청 데이터를 Action의 속성에 자동으로 바인딩합니다. Aware 인터페이스를 사용하려면 Aware 인터페이스에 정의된 공용 setter를 구현해야 하며, 이 setter 도 Aware 인터페이스 setter 이름과 일치하는 모든 요청 매개 변수에 자동으로 바인딩됩니다. 이 동작으로 인해 SessionAware, RequestAware, ApplicationAware 인터페이스에서 보여 준 것처럼 원격 공격자가 영향을 받는 인터페이스를 구현한 응용 프로그램에 조작된 매개 변수를 제공하여 런타임 데이터 값을 수정할 수 있습니다.

다음 URL을 통해 공격자가 세션 맵에서 "roles" 속성을 재정의할 수 있습니다. 이를 통해 공격자가 관리자가 될 수도 있습니다.

http://server/VulnerableAction?session.roles=admin


이러한 인터페이스에서는 setter 접근자 구현만 요구하지만 해당하는 getter 도 구현한 경우 이러한 맵 컬렉션 변경 사항은 현재 요청 범위에만 적용되는 것이 아니라 세션 범위 내에서 지속됩니다.

하나 이상의 Action Field에는 해당 검증 정의가 없습니다. 각 필드에는 ActionClass-validation.xml에서 참조한 명시적인 검증 루틴이 있어야 합니다.

개발자가 Action Form(작업 폼) 매핑을 삭제하거나 이름을 바꿀 때 검증 로직을 업데이트하는 것을 잊기 쉽습니다. 검증 로직이 올바로 유지 관리되고 있지 않음을 입증하는 한 가지 사례가 바로 검증 정의의 부족입니다.

검증 로직을 유지 관리하고 응용 프로그램의 나머지 부분과 동기화하는 것은 매우 중요합니다. 검증되지 않은 입력은 오늘날 가장 빈번하게 발생하고 가장 심각한 소프트웨어 보안 문제의 원인입니다. Cross-site scripting, SQL injection 및 process control 취약점은 모두 입력값 검증이 불완전하거나 없는 것에서 비롯됩니다. J2EE 응용 프로그램은 보통 메모리 손상 공격에는 취약하지 않지만 J2EE 응용 프로그램이 배열 범위 검사를 수행하지 않는 네이티브 코드와 상호 작용하는 경우, 공격자가 J2EE 응용 프로그램의 입력값 검증 실수를 이용하여 buffer overflow 공격을 가할 수 있습니다.

동일한 이름의 필드 유효성 검사기 참조가 ActionClass-validation.xml에 둘 이상 있습니다. 이름이 같은 검증 정의가 중복되어 있으면 예기치 않은 동작이 발생할 수 있습니다.

예제 1: 다음 항목은 중복된 필드 유효성 검사기 정의 2개를 보여줍니다.

   <field name="emailField">
      <field-validator type="email" short-circuit="true">
          <message>You must enter a value for email.</message>
      </field-validator>
      <field-validator type="email" short-circuit="true">
          <message>Not a valid email.</message>
      </field-validator>
  </field>
  

검증 로직을 유지 관리하고 응용 프로그램의 나머지 부분과 동기화하는 것은 매우 중요합니다. 검증되지 않은 입력은 오늘날 가장 빈번하게 발생하고 가장 심각한 소프트웨어 보안 문제의 원인입니다. Cross-Site Scripting, SQL Injection 및 Process Control 취약점은 모두 입력값 검증이 불완전하거나 없는 것에서 비롯됩니다. J2EE 응용 프로그램은 보통 메모리 손상 공격에는 취약하지 않지만 J2EE 응용 프로그램이 배열 범위 검사를 수행하지 않는 네이티브 코드와 상호 작용하는 경우, 공격자가 J2EE 응용 프로그램의 입력값 검증 실수를 이용하여 버퍼 오버플로 공격을 시작할 수 있습니다.

둘 이상의 ActionClass-validation.xml 파일이 이 Struts2 Action 정의에 대해 발견되었습니다. ActionClass의 폼으로 정의된 각 Struts2 Action에 대해 Struts2는 필요한 검증 제약 조건의 해당 ActionClass-validation.xml을 검색합니다. 배포에 하나의 작업에 대해 검증 정의가 여럿 있으면 예기치 못한 동작이 발생할 수 있습니다.

이름이 같은 Validation Form(검증 폼)이 두 개 있는 경우 Struts 유효성 검사기는 임의로 폼 중 하나를 선택하여 입력값 검증에 사용하고 나머지는 삭제합니다. 이 결정은 프로그래머의 예상과 일치하지 않을 수 있습니다. 뿐만 아니라, 검증 로직을 유지 관리하고 있지 않다는 것을 의미하고 다른 더 복잡한 검증 오류가 존재한다는 것을 의미할 수도 있습니다.

검증 로직을 유지 관리하고 응용 프로그램의 나머지 부분과 동기화하는 것은 매우 중요합니다. 검증되지 않은 입력은 오늘날 가장 빈번하게 발생하고 가장 심각한 소프트웨어 보안 문제의 원인입니다. Cross-site scripting, SQL injection 및 process control 취약점은 모두 입력값 검증이 불완전하거나 없는 것에서 비롯됩니다. J2EE 응용 프로그램은 보통 메모리 손상 공격에는 취약하지 않지만 J2EE 응용 프로그램이 배열 범위 검사를 수행하지 않는 네이티브 코드와 상호 작용하는 경우, 공격자가 J2EE 응용 프로그램의 입력값 검증 실수를 이용하여 buffer overflow 공격을 가할 수 있습니다.

validators.xml에서 둘 이상의 유효성 검사기 정의가 발견되었습니다. 이름이 같은 검증 정의가 여러 개 있으면 예기치 않은 동작이 발생할 수 있습니다.

2개의 검증 클래스가 동일한 이름으로 정의된 경우 Struts 유효성 검사기는 입력 검증에 사용할 형식 중 하나를 임의로 선택하고 다른 하나는 삭제합니다. 이 결정은 프로그래머의 예상과 일치하지 않을 수 있습니다. 그뿐만 아니라, 검증 로직을 유지 관리하고 있지 않다는 것을 의미하고 다른 더 복잡한 검증 오류가 존재한다는 것을 의미할 수도 있습니다.

검증 로직을 유지 관리하고 응용 프로그램의 나머지 부분과 동기화하는 것은 매우 중요합니다. 검증되지 않은 입력은 오늘날 가장 빈번하게 발생하고 가장 심각한 소프트웨어 보안 문제의 원인입니다. Cross-Site Scripting, SQL Injection 및 Process Control 취약점은 모두 입력값 검증이 불완전하거나 없는 것에서 비롯됩니다. J2EE 응용 프로그램은 보통 메모리 손상 공격에는 취약하지 않지만 J2EE 응용 프로그램이 배열 범위 검사를 수행하지 않는 네이티브 코드와 상호 작용하는 경우, 공격자가 J2EE 응용 프로그램의 입력값 검증 실수를 이용하여 버퍼 오버플로 공격을 시작할 수 있습니다.

Struts2는 Action 유효성 검사기 정의에서 사용자 지정 유효성 검사기를 사용하기 전에 validators.xml에서 정의할 것을 요구합니다. 유효성 검사기 참조가 누락되어 있으면 검증이 최신 상태가 아님을 나타냅니다.

예제 1: 다음 작업 유효성 검사기는 validators.xml에서 정의되지 않았습니다.

<validators>
    <validator name="required" class="com.opensymphony.xwork2.validator.validators.RequiredFieldValidator"/>
</validators>

검증 로직을 유지 관리하고 응용 프로그램의 나머지 부분과 동기화하는 것은 매우 중요합니다. 검증되지 않은 입력은 오늘날 가장 빈번하게 발생하고 가장 심각한 소프트웨어 보안 문제의 원인입니다. Cross-Site Scripting, SQL Injection 및 Process Control 취약점은 모두 입력값 검증이 불완전하거나 없는 것에서 비롯됩니다. J2EE 응용 프로그램은 보통 메모리 손상 공격에는 취약하지 않지만 J2EE 응용 프로그램이 배열 범위 검사를 수행하지 않는 네이티브 코드와 상호 작용하는 경우, 공격자가 J2EE 응용 프로그램의 입력값 검증 실수를 이용하여 버퍼 오버플로 공격을 시작할 수 있습니다.

확인되지 않은 입력은 J2EE 응용 프로그램 취약점의 주된 원인입니다. 확인되지 않은 입력은 Cross-Site Scripting, Process Control 및 SQL Injection 등 수많은 취약점을 야기할 수 있습니다. J2EE 응용 프로그램은 보통 메모리 손상 공격에는 취약하지 않지만 J2EE 응용 프로그램이 배열 범위 검사를 수행하지 않는 네이티브 코드와 상호 작용하는 경우, 공격자가 J2EE 응용 프로그램의 입력값 검증 실수를 이용하여 Buffer Overflow 공격을 가할 수 있습니다.

이런 공격을 막기 위해 Struts Validation 프레임워크를 사용하여 응용 프로그램이 처리하기 전에 모든 프로그램 입력을 검사합니다. Fortify Static Code Analyzer를 사용하여 Struts 유효성 검사기 구성에 아무런 허점이 없는지 확인합니다.

유효성 검사기 사용 예제에는 다음과 같은 검사가 포함됩니다.

- 전화 번호 필드에는 전화 번호로서 유효한 문자만 사용합니다.

- 부울 값은 "T"와 "F"뿐입니다.

- 자유 형식 문자열은 적절한 길이와 구성을 유지합니다.

일치하는 Struts2 Action이 없는 Struts2 검증 파일이 발견되었습니다. 각 ActionClass에 대해 Struts2는 필요한 검증 제약 조건에 해당하는 ActionClass-validation.xml을 검색합니다. 이 경우, ActionClass-validation.xml 형태의 검증 파일을 찾았지만 ActionClass가 Struts2 구성 파일에 정의된 Action과 일치하지 않습니다.

개발자가 Action Form(작업 폼) 매핑을 제거하거나 이름을 바꿀 때 검증 로직을 업데이트하는 것을 잊기 쉽습니다. 검증 로직이 올바로 유지 관리되고 있지 않음을 입증하는 한 가지 사례가 바로 Unused validation form의 존재입니다.

Struts2 유효성 검사기 정의가 존재하지 않는 작업 필드를 참조합니다.

개발자가 Action Form(작업 폼) 매핑을 제거하거나 이름을 바꿀 때 검증 로직을 업데이트하는 것을 잊기 쉽습니다. 검증 논리가 적절하게 유지 관리되지 않고 있다는 한 가지 징후는 분리된 Validator 정의가 있다는 것입니다.

여러 form-bean 태그에 동일한 이름이 사용되는 경우 마지막 항목만 등록되므로 중복된 <form-bean> 이름은 아무런 소용이 없습니다.

예제 1: 다음 구성에는 이름이 같은 2개의 form-bean 항목이 있습니다.

<form-beans>
  <form-bean name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
  <form-bean name="loginForm" type="org.apache.struts.validator.DynaActionForm">
    <form-property name="favoriteColor" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts는 path 속성을 사용하여 요청을 처리하는 데 필요한 리소스를 찾습니다. 경로는 모듈 상대 위치이므로 "/" 문자로 시작되지 않는 경로는 오류입니다.

예제 1: 다음 구성에는 빈 경로가 있습니다.

<global-exceptions>
  <exception key="global.error.invalidLogin" path="" scope="request" type="InvalidLoginException" />
</global-exceptions>

예제 2: 다음 구성은 "/" 문자로 시작되지 않는 경로를 사용합니다.

<global-forwards>
  <forward name="login" path="Login.jsp" />
</global-forwards>

Struts 사양은 명명된 작업에서 검증 오류를 반환할 때마다 input 속성을 요구합니다[2]. input 속성은 검증 오류가 발생할 때 오류 메시지를 표시하는 데 사용되는 페이지를 지정합니다.
예제 1: 다음 구성은 명명된 검증 작업을 정의하지만 input 속성을 지정하지 않습니다.

<action-mappings>
  <action   path="/Login"
            type="com.LoginAction"
            name="LoginForm"
            scope="request"
            validate="true" />
</action-mappings>