Ajax보안

Ajax보안

Ajax가 이용하는 HTTP 통신은 크로스 도메인 보안을 위해, 요청하는 url이 요청을 요구하는 페이지와 같은 도메인에 있어야한다.

다른도메인에서 JavaScript로는 접근할 수 없게 되어 있는것과 같은 이야기다. 이것은 각 브라우저에 제한 사항 이므로 제작시 신경 써야 하는 부분은 아니다.

다른 도메인의 데이터를 가공하기 위해 서버측 프록시를 뛰워 도메인을 넘어 데이터를 가져오는 방법도 있다고 한다. 이러한경우느 프록시가 보안의 구멍이 되지 않도록 주의 해야한다.

크로스 사이트 스크립트

기본적으로 웹프로그래밍을 하다보면 크로스 사이트 스크립트에 주의 해야한다. 이점은 Ajax도 마찬가지다. 크로스 사이트 스크립트는 사용자가 실수나 또는 임의로 html 태그를 섞어서 응답 데이터를 보낼수도 있다.

이러한 코드를 사용하지 못하도록 정규 표현식을 이용하거나 html 태그가 들어가지 못하도록 문자를 걸러내는 점이 필요하다.

SQL/OS 명령어 삽입 공격(Injection)

SQL Injection 이라는 것은 디비 쿼리문을 통한 공격을 애기한다. 운영되고 있는 사이트에 디비에서 데이터를 호출하여 Ajax를 이용할때는 디비쿼리문을 삽입하여 공격하는것에 대해 주의 해야 한다.

사용자가 DROPT TABLE 형태로 sql을 삽입하여 테이블도 날려버릴수 있으므로 PHP를 예로 들자면 mysql_escape_string(), sqlite_escape_string() 함수를 이용해 특수문자를 처리해야 한다. 

OS 명령어를 주입하여 공격하는 일도 일어날수 있으므로 주의가 필요하다.

system(), 백워드(')등 쉘명령어를 이용할 경우 OS 명령어를 주입하여 공격이 일어날수 있다.

escapeshellcmd(), escapeshellarg() 함수를 이용하여 방어를 막아야 한다.

또한 php.ini에서 magic_quotes_gpc가 on 되어 있다면 자동으로 get/post/cookies 로 넘겨지는 것들을 작은 따옴표 큰따옴표 백슬래스 및 null을 자동적으로 처리되지만 실제로 동작을 체크해 보는것이 필요하고 신중해야한다.

악의 적인 코드가 자기가 관리하고 있는 곳에서 일어나지 않을것이라고 생각하지 않아야 하낟.

암호 파일 관리

암호가 들어있는 정보는 당연히 JavaScript에 넣어두면 안된다. 물론 서버측 스크립트에도 넣어두면 안된다.

HTTP 서버 장애 발생시 php 같은 서버측 코드가 그대로 보여질 가능성있다. 

서버측 암호 파일도 암호화해서 웹으로 공개되지 않는 디렉토리에 보관해야 할것이다.

스크립트 무효화

공격	스크립트	언어	대책
SQL 삽입공격	MySQL	PHP	$code = mysql_escape_string($_GET['code']);
OS 삽입 공격	Linux	PHP	$text = escapeshellarg($text);
크로스 사이트 스크립트		PHP	$data = htmlspecialchars($data);