반응형
제목: 웹 애플리케이션의 보안 테스팅을 위한 접근방식(An approach for Security Testing of Web Applications)
저자: Inder P Singh
문서유형: 웹 문서, 2015년
출처: http://www.softwaretestinghelp.com/security-testing-of-web-applications/
웹 애플리케이션의 보안 테스팅
- 점점 더 민감한 데이터가 웹 애플리이션에 저장되고 웹 상의 거래 수도 증가함에 따라 웹 애플리케이션의 적절한 보안 테스팅이 매우 중요해짐
- 보안 테스팅은 비밀 정보가 비밀로 남으며(즉, 의도되지 않은 개인/독립체에게 노출되지 않음) 사용자는 수행할 권한을 부여 받은 태스크만 수행 할 수 있는지를 판단하는 프로세스이다.
- 보안 테스트의 목적은 웹 애플리케이션의 취약점(vulnerabilities)을 발견하고, 이를 개발자가 제거하여 웹 애플리케이션과 데이터를 인가되지 않은 행위로부터 안전하도록 만드는데 있다.
웹 애플리케이션 보안 테스팅에서 흔히 사용되는 주요 용어
- 취약성(Vulnerability): 웹 애플리케이션에 있는 약점. 이런 약점의 원인으로 애플리케이션 상의 버그, 삽입(SQL/스크립트 코드), 또는 바이러스의 존재 등이 있다.
- URL 조작(URL manipulation): 일부 웹 애플리케이션은 URL에서 클라이언트(브라우저)와 서버 간 추가적 정보를 주고 받음. URL에서 어떤 정보를 변경하는 것이 간혹 서버의 의도치 않은 동작으로 이어질 수도 있다.
- SQL 삽입(SQL injection): SQL 문장을 웹 애플리케이션 UI를 통해 서버에 의해 실행되는 어떤 쿼리로 삽입시키는 프로세스
- XSS(Cross Site Scripting): 사용자가 웹 애플리케이션의 UI에 HTML/클라이언트측 스크립트를 삽입하고, 이 삽입이 다른 사용자에게 보일 때 이것을 XSS라 지칭함
- 스푸핑(Spoofing): 가짜로 비슷한 (위장) 웹사이트/이메일을 생성하는 것
보안 테스팅 접근방식
웹 애플리케이션의 유용한 보안 테스트를 수행하기 위해서는 보안 테스터가 HTTP 프로토콜을 잘 알고 있어야 하며, 클라이언트(브라우저)와 서버가 HTTP를 사용해 어떻게 의사소통 하는지를 이해하는 것도 중요하다. 또한 테스터가 SQL 삽입과 XSS에 대한 최소한 기본적인 것들을 알고 있어야 한다.
1. 패스워드 깨기(Password cracking)
- 웹 애플리케이션 상의 보안 테스팅은 “패스워드 깨기(password cracking)”에서부터 시작할 수 있다.
- 애플리케이션의 사적 영역에 로그인 하기 위해서 공격자가 사용자명/패스워드를 추측하거나 또는 패스워드 깨기 도구(password cracker tool)를 활용할 수 있다. 오픈 소스 패스워드 크랙커와 함께 흔한 사용자명/패스워드의 목록이 가용함
- 웹 애플리케이션이 복잡한 패스워드를 강요하지 않으면 사용자명과 패스워드를 깨는데 별로 오래 걸리지 않을 수도 있음
- 사용자명 또는 패스워드가 암호화 없이 쿠키에 저장되면 공격자가 다른 방법을 사용해 쿠키를 훔칠 수 있다(즉, 사용자명/패스워드 같은 쿠키에 저장된 정보를 훔침).
2. HTTP GET 메쏘드를 통한 URL 조작
- 테스터는 애플리케이션이 혹시 중요 정보를 쿼리스트링(querystring)에 전달하는지 체크해야 한다(애플리케이션이 클라이언트와 서버간 정보를 전달하는데 HTTP GET 메쏘드를 사용할 때 이런 일이 발생). 정보가 쿼리스트링의 패러미터에서 전달됨. 테스터는 서버가 이것을 받아들이는지 체크하기 위해 쿼리스트링의 패러미터 값을 변경할 수 있음
- 인증(authentication) 또는 데이터 가져오기(fetching data)를 위해서 사용자 정보가 HTTP GET 리퀘스트를 통해 서버로 전달됨. 공격자는 원하는 정보를 얻기 위해(또는 데이터를 훼손시키기 위해) 이 GET 리퀘스트로부터 서버로 전달되는 모든 입력 값을 조작할 수 있다. 이런 조건에서는 애플리케이션 또는 웹 서버에 의한 어떤 일상적이지 않은 동작도 공격자가 애플리케이션으로 침입하는 출입구가 될 수 있다.
3. SQL 삽입
- 테스터가 다음으로 체크해야 할 것이 SQL 삽입이다. 텍스트박스에 단일 인용 부호(‘)를 입력하는 것을 애플리케이션이 거부해야 하며, 그렇지 않고 테스터가 데이터베이스 에러를 마주치게 되면 사용자 입력이 어떤 쿼리에 삽입되었고 이것이 애플리케이션에 의해 실행되었음을 의미함. 이 경우 해당 애플리케이션이 ‘SQL 삽입’에 취약
- SQL 삽입 공격은 공격자가 서버 데이터베이스로부터 중요 정보를 빼내갈 수 있으므로 매우 심각함. 웹 애플리케이션으로의 SQL 삽입 입구(entry points)를 체크하기 위해서는 어떤 사용자 입력을 받아들임으로써 직접적인 MySQL 쿼리가 데이터베이스 상에서 실행되는 코드 부분을 코드베이스로부터 찾아야 함
- 만일 사용자 입력 데이터가 데이터베이스를 쿼리하기 위해서 SQL 쿼리문에 들어간다면, 공격자는 데이터베이스로부터 중요 정보를 끌어내기 위해 SQL 문장(또는 SQL 문장의 일부)을 사용자 입력으로써 삽입시킬 수 있음. 공격자가 애플리케이션을 크래시 하도록 만든다 해도 브라우저 상에 보여지는 SQL 쿼리 에러로부터 공격자는 원하는 정보를 얻을 수 있다. 이런 경우 사용자 입력으로부터의 특수 문자가 제대로 처리되어야 함
4. 크로스 사이트 스크립팅(XSS)
- 테스터가 XSS(Cross site scripting)에 대해 웹 애플리케이션을 추가적으로 체크해야 한다. 어떤 HTML(예, <HTML> 또는 <SCRIPT> 같은 스크립트)도 애플리케이션이 받아 들여서는 안되며, 만약 받아들인다면 애플리케이션이 XSS 공격을 받기 쉽다.
- 공격자가 피해자의 브라우저 상에서 악의적인 스크립트/URL을 실행하기 위해서 이 방법을 사용할 수 있다. XSS을 사용하면 공격자가 사용자 쿠키(그리고 쿠키에 저장된 정보)를 훔치는데 JavaScript 같은 스크립트를 사용할 수 있다.
- 공격자가 악의적인 입력 또는 <script>를 브라우저 상의 중요한 사용자/서버 데이터를 탐색할 수 있는 ‘&query’ 패러미터로써 쉽게 전달할 수 있다.
!! 중요: 보안 테스팅 동안 테스터는 아래의 어떤 것도 변경시키지 않도록 매우 주의해야 한다.
- 애플리케이션 또는 서버의 구성(Configuration)
- 서버 상에서 돌아가고 있는 서비스
- 애플리케이션에 의해 호스팅되는 기존 사용자/고객 데이터
또한 보안 테스트는 운영 중인 생산 시스템(a production system) 상에서는 피해야 한다.
반응형
'테스팅타입별 > 보안(Security)' 카테고리의 다른 글
| 책 발췌 – 보안 테스팅 by Everett and McLeod (1) | 2024.02.26 |
|---|---|
| 책 요약정리 – 웹 보안 우려사항 by Nguyen (0) | 2021.05.17 |
| 문서요약 - 버그 배틀 우승자의 보안 테스팅 조언 by Lelchuk (0) | 2019.02.11 |
| 문서요약 - 웹 애플리케이션 보안 문제의 이해 by Rational Software (0) | 2019.02.04 |
| 페이퍼요약 - 소프트웨어 보안 테스팅 by POTTER (0) | 2019.01.28 |