Cross-Site Scripting: Inter-Component Communication (Cloud)

검증되지 않은 데이터를 웹 브라우저에 보내면 브라우저가 악성 코드를 실행하는 결과를 초래할 수 있습니다.

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

1. 데이터가 신뢰할 수 없는 소스를 통해 클라우드에서 호스팅되는 웹 응용 프로그램에 입력됩니다. Inter-Component Communication Cloud XSS의 경우 신뢰할 수 없는 소스는 클라우드 호스트가 제공하는 통신 채널을 통해 클라우드 응용 프로그램의 다른 구성 요소에서 수신한 데이터입니다.


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

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

예제 1: 다음 ASP.NET 웹 폼은 Azure 테이블 서비스에 직원을 쿼리하여 이름을 인쇄합니다.

<script runat="server">
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.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;
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;

이 코드 예제는 Name의 값이 올바로 동작할 때는 정확하게 기능을 하지만 그렇지 않을 때는 익스플로이트를 방지하기 위한 아무 조치도 취하지 않습니다. 이 코드는 Name의 값을 분산 응용 프로그램이 컨텐츠를 분명하게 관리하는 클라우드 제공 스토리지 서비스에서 읽기 때문에 위험하지 않은 것으로 보일 수 있습니다. 하지만 Name의 값이 사용자가 제공하는 데이터에서 오는 경우 클라우드 제공 스토리지 서비스는 악성 컨텐츠의 통로가 될 수 있습니다. 데이터베이스에 저장된 모든 데이터에 대한 적절한 입력값 검증 절차가 없으면 공격자는 사용자의 웹 브라우저에서 악의적인 명령을 실행할 수 있습니다. 이런 유형의 익스플로이트를 Inter-Component Communication Cloud 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에서처럼 응용 프로그램은 데이터베이스 또는 다른 신뢰할 수 있는 데이터 저장소에 데이터를 저장합니다. 그러면 위험한 데이터는 응용 프로그램이 다시 읽어 들여 동적 콘텐트에 포함시킵니다. Inter-Component Communication Cloud 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은 입력 소스에 적용된 검증 메커니즘에 따라 문제를 폴더로 그룹화하는 데이터 유효성 프로젝트 템플릿을 사용 가능하게 만듭니다.