SQL Injection: JDO

JDO(Java Data Objects)를 사용하여 신뢰할 수 없는 소스에서 나온 입력으로 만들어진 동적 SQL 또는 JDOQL 문을 실행하면 공격자가 해당 문의 의미를 수정하거나 임의의 SQL 명령을 실행할 수 있습니다.

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

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



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

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

...
	String userName = ctx.getAuthenticatedUserName();
	String itemName = request.getParameter("itemName");
	String sql = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ itemName + "'";
	Query query = pm.newQuery(Query.SQL, sql);
	query.setClass(Person.class);
	List people = (List)query.execute();
	...

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

	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 공격을 방지하는 한 가지 기존의 접근 방식은 공격을 입력값 검증 문제로 처리하고 안전한 값 목록(허용 목록)의 문자만 받거나 악의적일 가능성이 있는 값 목록(거부 목록)을 식별하여 이스케이프 처리하는 것입니다. 허용 목록 검사가 엄격한 입력값 검증 규칙을 이행하는 효과적인 수단이 되기도 하지만, 매개 변수가 있는 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 공격에 대해 안전하게 보호할 수는 없습니다.