해커 그룹 인 Anonymous 및 LulzSec의 이벤트를 느슨하게 따랐더라도 악명 높은 Sony 해킹과 같이 해킹당하는 웹 사이트와 서비스에 대해 들어 보셨을 것입니다. 그들이 어떻게하는지 궁금한 적이 있습니까?
이러한 그룹에서 사용하는 도구와 기술은 여러 가지가 있습니다.이 작업을 직접 수행하기위한 설명서를 제공하지는 않지만 진행 상황을 이해하는 것이 유용합니다. 이러한 공격에 대해 지속적으로 듣고있는 두 가지 공격은 "(분산) 서비스 거부"(DDoS) 및 "SQL 주입"(SQLI)입니다. 작동 방식은 다음과 같습니다.
이미지 xkcd
서비스 거부 공격
뭔데?
"서비스 거부"( "분산 서비스 거부"또는 DDoS라고도 함) 공격은 시스템 (이 경우 웹 서버)이 한 번에 너무 많은 요청을 수신하여 서버 리소스가 과부하되어 시스템이 잠길 때 발생합니다. 종료됩니다. 성공적인 DDoS 공격의 목표와 결과는 합법적 인 트래픽 요청에 대상 서버의 웹 사이트를 사용할 수 없다는 것입니다.
어떻게 작동합니까?
DDoS 공격의 물류는 예를 통해 가장 잘 설명 될 수 있습니다.
백만 명의 사람들 (공격자)이 콜센터를 무너 뜨려 Company X의 비즈니스를 방해하려는 목표에 모였다 고 상상해보십시오. 공격자들은 화요일 오전 9시에 모두 회사 X의 전화 번호로 전화를 걸도록 조정합니다. 대부분의 경우 Company X의 전화 시스템은 한 번에 백만 건의 통화를 처리 할 수 없으므로 모든 수신 회선이 공격자에 의해 묶여집니다. 그 결과 합법적 인 고객 전화 (즉, 공격자가 아닌 전화)는 전화 시스템이 공격자의 전화를 처리하는 데 묶여 있기 때문에 전달되지 않습니다. 따라서 본질적으로 Company X는 합법적 인 요청을 통과 할 수 없기 때문에 잠재적으로 비즈니스를 잃을 수 있습니다.
웹 서버에 대한 DDoS 공격은 똑같은 방식으로 작동합니다. 웹 서버가 요청을 처리 할 때까지 합법적 인 요청과 공격자로부터 어떤 트래픽이 발생하는지 알 수있는 방법이 거의 없기 때문에 이러한 유형의 공격은 일반적으로 매우 효과적입니다.
공격 실행
DDoS 공격의 "무력"특성으로 인해 동시에 공격 할 수 있도록 조정 된 많은 컴퓨터를 보유해야합니다. 콜 센터 예를 다시 살펴보면 모든 공격자가 오전 9시에 전화를 걸고 실제로 그 시간에 전화해야한다는 것을 알아야합니다. 이 원칙은 웹 서버를 공격 할 때 확실히 작동하지만 실제 유인 컴퓨터 대신 좀비 컴퓨터를 사용하면 훨씬 쉬워집니다.
아시다시피, 악성 코드 및 트로이 목마의 변종이 많이 있습니다. 시스템에 한 번은 휴면 상태에 있으며 때때로 지침을 위해 "전화 홈"으로 사용됩니다. 예를 들어 이러한 지침 중 하나는 오전 9시에 Company X의 웹 서버에 반복적 인 요청을 보내는 것입니다. 따라서 각 멀웨어의 홈 위치에 대한 단일 업데이트를 통해 단일 공격자는 수십만 대의 손상된 컴퓨터를 즉시 조정하여 대규모 DDoS 공격을 수행 할 수 있습니다.
좀비 컴퓨터를 활용하는 장점은 효율성뿐 아니라 공격자가 실제로 자신의 컴퓨터를 사용하여 공격을 실행할 필요가 없기 때문에 익명성에 있습니다.
SQL 주입 공격
뭔데?
"SQL 주입"(SQLI) 공격은 열악한 웹 개발 기술을 활용하고 일반적으로 결함이있는 데이터베이스 보안과 결합되는 공격입니다. 성공적인 공격의 결과는 사용자 계정을 가장하는 것부터 각 데이터베이스 또는 서버의 완전한 손상에 이르기까지 다양합니다. DDoS 공격과 달리 SQLI 공격은 웹 애플리케이션이 적절하게 프로그래밍 된 경우 완전하고 쉽게 예방할 수 있습니다.
공격 실행
웹 사이트에 로그인하고 사용자 이름과 암호를 입력 할 때마다 자격 증명을 테스트하기 위해 웹 응용 프로그램에서 다음과 같은 쿼리를 실행할 수 있습니다.
사용자 이름 = 'myuser'및 암호 = 'mypass'에서 사용자 ID 선택;
참고 : SQL 쿼리의 문자열 값은 작은 따옴표로 묶어야하므로 사용자가 입력 한 값 주위에 표시됩니다.
따라서 입력 한 사용자 이름 (myuser)과 암호 (mypass)의 조합은 UserID가 반환 되려면 Users 테이블의 항목과 일치해야합니다. 일치하는 항목이 없으면 사용자 ID가 반환되지 않으므로 로그인 자격 증명이 유효하지 않습니다. 특정 구현은 다를 수 있지만 메커니즘은 꽤 표준입니다.
이제 사용자가 웹 양식에 입력 한 값을 대체 할 수있는 템플릿 인증 쿼리를 살펴 보겠습니다.
사용자 이름 = '[user]'및 암호 = '[pass]'에서 사용자 ID 선택
언뜻보기에 이것은 사용자를 쉽게 검증하기위한 간단하고 논리적 인 단계처럼 보일 수 있지만이 템플릿에서 사용자가 입력 한 값의 간단한 대체가 수행되면 SQLI 공격에 취약합니다.
예를 들어 사용자 이름 필드에 "myuser"– "를 입력하고 암호에"wrongpass "를 입력했다고 가정합니다. 템플릿 쿼리에서 간단한 대체를 사용하면 다음과 같은 결과를 얻을 수 있습니다.
사용자 이름 = 'myuser'- 'AND Password ='wrongpass '에서 사용자 ID 선택
이 진술의 핵심은 두 개의 대시를 포함하는 것입니다.
(--)
. 이것은 SQL 문의 주석 시작 토큰이므로 두 개의 대시 (포함) 뒤에 나타나는 모든 것은 무시됩니다. 기본적으로 위 쿼리는 데이터베이스에서 다음과 같이 실행됩니다.
사용자 이름 = 'myuser'에서 사용자 ID 선택
여기서 눈에 띄는 누락은 암호 확인이 없다는 것입니다. 사용자 필드의 일부로 두 개의 대시를 포함함으로써 우리는 암호 확인 조건을 완전히 우회하고 각각의 암호를 몰라도 "myuser"로 로그인 할 수있었습니다. 의도하지 않은 결과를 생성하기 위해 쿼리를 조작하는 이러한 행위는 SQL 주입 공격입니다.
어떤 손상을 입힐 수 있습니까?
SQL 인젝션 공격은 부주의하고 무책임한 애플리케이션 코딩으로 인해 발생하며 완전히 예방할 수 있지만 (잠시 후 다룰 예정입니다), 수행 할 수있는 손상의 정도는 데이터베이스 설정에 따라 다릅니다. 웹 애플리케이션이 백엔드 데이터베이스와 통신하려면 애플리케이션이 데이터베이스에 대한 로그인을 제공해야합니다 (참고 : 이것은 웹 사이트 자체에 대한 사용자 로그인과 다름). 웹 애플리케이션에 필요한 권한에 따라이 각 데이터베이스 계정은 기존 테이블의 읽기 / 쓰기 권한부터 전체 데이터베이스 액세스에 이르기까지 모든 것을 요구할 수 있습니다. 이것이 지금 명확하지 않은 경우 몇 가지 예를 통해 명확성을 제공 할 수 있습니다.
위의 예에 따라 예를 들어 다음을 입력하여 확인할 수 있습니다.
"youruser '-", "admin'-"
또는 다른 사용자 이름이 있으면 암호를 몰라도 해당 사용자로 사이트에 즉시 로그인 할 수 있습니다. 시스템에 들어가면 실제로 해당 사용자가 아니라는 사실을 알 수 없으므로 해당 계정에 대한 전체 액세스 권한이 있습니다. 일반적으로 웹 사이트는 해당 데이터베이스에 대한 읽기 / 쓰기 액세스 권한이 있어야하기 때문에 데이터베이스 권한은 이에 대한 안전망을 제공하지 않습니다.
이제 웹 사이트가 레코드 삭제, 테이블 추가 / 제거, 새 보안 계정 추가 등의 기능을 제공하는 각 데이터베이스에 대한 모든 권한을 가지고 있다고 가정합니다. 일부 웹 응용 프로그램에는 이러한 유형의 권한이 필요할 수 있습니다. 모든 권한이 부여되는 것이 자동으로 나쁜 것은 아닙니다.
따라서 이러한 상황에서 발생할 수있는 피해를 설명하기 위해 사용자 이름 필드에 다음을 입력하여 위의 만화에 제공된 예를 사용합니다.
"Robert '; DROP TABLE 사용자;-".
단순 대체 후 인증 쿼리는 다음과 같습니다.
사용자 이름 = 'Robert'에서 사용자 ID 선택; DROP TABLE Users;- 'AND Password ='wrongpass '
참고 : 세미콜론은 SQL 쿼리에서 특정 문의 끝과 새 문의 시작을 나타내는 데 사용됩니다.
다음과 같이 데이터베이스에서 실행됩니다.
사용자 이름 = 'Robert'에서 사용자 ID 선택DROP TABLE 사용자
그래서 우리는 전체 Users 테이블을 삭제하기 위해 SQLI 공격을 사용했습니다.
물론 허용되는 SQL 권한에 따라 공격자가 값을 변경하거나 테이블 (또는 전체 데이터베이스 자체)을 텍스트 파일로 덤프하거나 새 로그인 계정을 만들거나 전체 데이터베이스 설치를 가로 챌 수 있으므로 훨씬 더 나쁜 일이 발생할 수 있습니다.
SQL 주입 공격 방지
이전에 여러 번 언급했듯이 SQL 주입 공격은 쉽게 예방할 수 있습니다. 웹 개발의 기본 규칙 중 하나는 위의 템플릿 쿼리에서 간단한 대체를 수행했을 때처럼 사용자 입력을 맹목적으로 신뢰하지 않는다는 것입니다.
SQLI 공격은 입력 내용을 삭제 (또는 이스케이프)하는 방식으로 쉽게 차단됩니다. 삭제 프로세스는 본질적으로 SQL 문 내에서 문자열을 조기에 종료하는 데 사용할 수 없도록 인라인 작은 따옴표 (‘) 문자를 적절하게 처리하는 것이므로 실제로 매우 간단합니다.
예를 들어 데이터베이스에서 "O’neil"을 조회하려는 경우 O 뒤의 작은 따옴표로 인해 문자열이 너무 일찍 끝나기 때문에 단순 대체를 사용할 수 없습니다. 대신 각 데이터베이스의 이스케이프 문자를 사용하여 삭제합니다. 인라인 작은 따옴표의 이스케이프 문자가 각 따옴표 앞에 \ 기호가 있다고 가정 해 보겠습니다. 따라서“O’neal”은“O’neil”로 삭제됩니다.
이 간단한 위생 조치는 SQLI 공격을 거의 방지합니다. 설명을 위해 이전 예제를 다시 살펴보고 사용자 입력이 삭제 될 때 결과 쿼리를 살펴 보겠습니다.
myuser '-
/
잘못된 패스
:
UserName = 'myuser \'- 'AND Password ='wrongpass '에서 사용자 ID 선택
myuser 뒤의 작은 따옴표가 이스케이프되기 때문에 (즉, 대상 값의 일부로 간주 됨) 데이터베이스는 문자 그대로 다음의 UserName을 검색합니다.
"myuser '-".
또한 대시는 SQL 문 자체가 아니라 문자열 값 내에 포함되기 때문에 SQL 주석으로 해석되는 대신 대상 값의 일부로 간주됩니다.
Robert '; DROP TABLE 사용자;-
/
잘못된 패스
:
UserName = 'Robert \'에서 사용자 ID 선택; DROP TABLE Users;- 'AND Password ='wrongpass '
Robert 뒤의 작은 따옴표를 간단히 이스케이프하면 세미콜론과 대시가 모두 UserName 검색 문자열에 포함되므로 데이터베이스가 문자 그대로 검색합니다.
"Robert '; DROP TABLE 사용자;-"
테이블 삭제를 실행하는 대신.
요약하자면
웹 공격이 진화하고 더 정교 해 지거나 다른 진입 점에 집중되는 동안,이를 악용하도록 설계된 무료로 사용할 수있는 여러 "해커 도구"의 영감이 된 시도되고 실제 공격으로부터 보호하는 것을 기억하는 것이 중요합니다.
DDoS와 같은 특정 유형의 공격은 쉽게 피할 수 없지만 SQLI와 같은 공격은 피할 수 있습니다. 그러나 이러한 유형의 공격으로 인해 발생할 수있는 피해는 취한 예방 조치에 따라 불편한 것부터 재앙적인 것까지 다양합니다.
