해커들이 SQL 주입 및 DDoS로 웹 사이트를 인수하는 방법

해커 그룹 Anonymous와 LulzSec의 이벤트를 느슨하게 따랐다 고해도, 악명 높은 Sony 해킹과 같이 해킹당한 웹 사이트와 서비스에 대해 들었을 것입니다. 그들이 어떻게하는지 궁금해 본적이 있습니까??

이 그룹들이 사용하는 여러 가지 도구와 기술이 있으며 사용자가 직접이 작업을 수행 할 수있는 설명서는 제공하지 않지만 실제로 진행되는 작업을 이해하는 것은 유용합니다. 그들이 지속적으로 사용하는 두 가지 공격은 "(분산 된) 서비스 거부"(DDoS)와 "SQL 주입"(SQLI)입니다. 작동 방식은 다음과 같습니다..

이미지 작성자 : xkcd

서비스 거부 공격

무엇입니까??

시스템 (이 경우 웹 서버)이 한 번에 너무 많은 요청을 수신하여 서버 자원에 과부하가 걸리면 "서비스 거부"(때로는 "분산 서비스 거부"또는 DDoS 공격) 공격이 발생합니다. 시스템이 단순히 잠김 닥쳐. 성공적인 DDoS 공격의 목표와 결과는 합법적 인 트래픽 요청에서 대상 서버의 웹 사이트를 사용할 수 없다는 것입니다.

어떻게 작동하나요??

DDoS 공격의 물류는 예제를 통해 가장 잘 설명 될 수 있습니다.

100 만 명의 사람들 (공격자)이 콜센터를 무너 뜨리는 X 회사의 사업을 방해하려는 목표를 가지고 있다고 상상해보십시오. 공격자는 화요일 오전 9시에 회사 X의 전화 번호로 전화를 걸도록 조정합니다. 아마도 X 사의 전화 시스템은 한번에 100 만 건의 전화를 처리 할 수 ​​없으므로 모든 수신 회선이 공격자에 의해 묶일 것입니다. 그 결과 합법적 인 고객 통화 (즉, 공격자가 아닌 통화)는 전화 시스템이 공격자의 통화를 처리하기 때문에 연결되지 않습니다. 그래서 본질적으로 회사 X는 합법적 인 요청이 통과 할 수 없기 때문에 사업을 잃을 가능성이 있습니다.

웹 서버에 대한 DDoS 공격은 똑같은 방식으로 작동합니다. 웹 서버가 요청을 처리 할 때까지 합법적 인 요청과 공격자간에 어떤 트래픽이 공급되는지를 알 수있는 방법이 거의 없기 때문에 이러한 유형의 공격은 일반적으로 매우 효과적입니다.

공격 실행

DDoS 공격의 "무차별적인"특성으로 인해 동시에 공격하기 위해 많은 컴퓨터를 모두 조정해야합니다. 콜센터의 예를 다시 들자면, 모든 공격자는 오전 9시에 전화를 걸고 실제로 그 시간에 전화를해야합니다. 이 원칙은 웹 서버를 공격 할 때 분명히 효과적 일 수 있지만 실제 유인 컴퓨터 대신 좀비 컴퓨터가 사용되면 훨씬 쉽게됩니다.

이미 알고 계시 겠지만, 한 번 시스템에 침입하면 휴면 상태가되며 때로는 "집으로 전화"하여 지침을 얻는 악성 코드 및 트로이 목마가 많이 있습니다. 이 지침 중 하나는 예를 들어 오전 9시에 회사 X의 웹 서버에 반복 요청을 보내는 것입니다. 따라서 각 악성 코드의 홈 위치를 한 번 업데이트하면 한 명의 침입자가 수십만 대의 손상된 컴퓨터를 즉시 조정하여 방대한 DDoS 공격을 수행 할 수 있습니다.

좀비 컴퓨터를 사용하는 것의 효과는 효과적 일뿐만 아니라 공격자가 실제로 컴퓨터를 사용하여 공격을 수행 할 필요가 없기 때문에 익명성에 있습니다.

SQL 주입 공격

무엇입니까??

"SQL 주입"(SQL injection) 공격은 취약한 웹 개발 기술을 활용하고 일반적으로 오류가있는 데이터베이스 보안과 결합 된 공격입니다. 공격 성공의 결과는 사용자 계정을 가장하여 해당 데이터베이스 또는 서버를 완전히 손상시킬 수 있습니다. DDoS 공격과 달리 SQLI 공격은 웹 응용 프로그램이 적절히 프로그래밍 된 경우 완벽하고 쉽게 예방할 수 있습니다.

공격 실행

웹 사이트에 로그인하고 사용자 이름과 암호를 입력 할 때마다 자격 증명을 테스트하기 위해 웹 응용 프로그램은 다음과 같은 쿼리를 실행할 수 있습니다.

UserName = "myuser"및 Password = "mypass"인 사용자로부터 SELECT 사용자 ID;

참고 : SQL 쿼리의 문자열 값은 작은 따옴표로 묶어야합니다.이 값은 사용자가 입력 한 값 주변에 나타나는 이유입니다.

따라서 입력 한 사용자 이름 (myuser)과 암호 (mypass)의 조합은 UserID가 반환되도록 Users 테이블의 항목과 일치해야합니다. 일치하는 항목이 없으면 사용자 ID가 반환되지 않으므로 로그인 자격 증명이 유효하지 않습니다. 특정 구현이 다를 수 있지만 메커니즘은 꽤 표준 적입니다..

이제 사용자가 웹 양식에 입력하는 값으로 대체 할 수있는 템플릿 인증 쿼리를 살펴 보겠습니다.

UserName = "[user]"AND 암호 = "[pass]"사용자의 SELECT 사용자 ID

언뜻보기에 이것은 사용자를 쉽게 확인하기위한 간단하고 논리적 인 단계처럼 보일 수 있습니다. 그러나 사용자 입력 값의 간단한 대체가이 템플리트에서 수행되면 SQLI 공격에 취약합니다.

예를 들어, "myuser'-"가 사용자 이름 필드에 입력되고 "wrongpass"가 암호에 입력되었다고 가정합니다. 템플릿 쿼리에서 간단한 대체를 사용하면 다음과 같이됩니다.

SELECT UserID from Users WHERE UserName = "myuser"- 'AND Password = "wrongpass"

이 문장의 핵심은 두 개의 대시 (-). 이것은 SQL 문에 대한 시작 주석 토큰이므로 두 개의 대시 (inclusive) 다음에 나타나는 모든 항목은 무시됩니다. 기본적으로 위 쿼리는 다음과 같이 데이터베이스에 의해 실행됩니다.

사용자로부터 SELECT 사용자 ID WHERE UserName = "myuser"

여기서 눈부신 누락은 암호 확인이 부족하다는 것입니다. 두 개의 대시를 사용자 필드의 일부로 포함시킴으로써 우리는 비밀번호 확인 조건을 완전히 무시하고 각각의 비밀번호를 모른 채 "myuser"로 로그인 할 수있었습니다. 의도하지 않은 결과를 생성하기 위해 쿼리를 조작하는 행위는 SQL 주입 공격.

어떤 피해를 입을 수 있습니까??

SQL 주입 공격은 부주의하고 무책임한 응용 프로그램 코딩으로 인해 발생하며 완벽하게 예방할 수 있습니다 (잠시 후에 다룰 예정 임). 그러나 수행 할 수있는 손상 정도는 데이터베이스 설정에 따라 다릅니다. 웹 응용 프로그램이 백엔드 데이터베이스와 통신하려면 응용 프로그램이 데이터베이스에 로그인해야합니다 (이는 웹 사이트 자체에 대한 사용자 로그인과 다릅니다). 웹 응용 프로그램에 필요한 사용 권한에 따라이 각각의 데이터베이스 계정은 기존 테이블의 읽기 / 쓰기 권한 만 전체 데이터베이스 액세스 권한으로 요구할 수 있습니다. 이것이 현재 명확하지 않은 경우 몇 가지 예가 명확성을 제공해야합니다..

위의 예를 기반으로 볼 때, 예를 들어,, "youruser '-", "admin'-" 또는 다른 사용자 이름을 사용하면 암호를 모른 채 즉시 해당 사용자로 사이트에 로그인 할 수 있습니다. 우리가 시스템에 들어가게되면 우리는 실제로 그 사용자가 아니므로 해당 계정에 대한 모든 권한을 갖게됩니다. 일반적으로 웹 사이트는 최소한 해당 데이터베이스에 대한 읽기 / 쓰기 액세스 권한을 가져야하므로 데이터베이스 사용 권한은 안전망을 제공하지 않습니다.

이제 웹 사이트가 레코드 삭제, 테이블 추가, 새 보안 계정 추가 등의 기능을 제공하는 해당 데이터베이스에 대한 모든 권한을 가지고 있다고 가정 해 봅니다. 일부 웹 응용 프로그램에는 이러한 유형의 권한이 필요할 수 있으므로 완전히 통제 할 수있는 것은 나쁜 것이 아닙니다..

따라서이 상황에서 발생할 수있는 피해를 설명하기 위해 위의 만화에서 제공된 예제를 사용자 이름 필드에 다음을 입력하여 사용합니다. "Robert"; 사용자 테이블 삭제 - "". 간단한 대체 후 인증 쿼리는 다음과 같습니다.

사용자 ID에서 SELECT 사용자 ID WHERE UserName = "Robert"; DROP TABLE 사용자; - 'AND 암호 = "wrongpass"

참고 : SQL 문의 세미콜론은 특정 명령문의 끝과 새로운 명령문의 시작을 나타내는 데 사용됩니다.

데이터베이스에서 다음과 같이 실행됩니다.

UserName에서 사용자 ID를 선택하십시오. UserName = "Robert"

DROP TABLE 사용자

그래서 우리는 SQLI 공격을 사용하여 Users 테이블 전체를 삭제했습니다..

물론 허용되는 SQL 사용 권한에 따라 공격자가 값을 변경하거나, 테이블 또는 전체 데이터베이스 자체를 텍스트 파일로 덤프하거나, 새 로그인 계정을 만들거나, 전체 데이터베이스 설치를 도용 할 수 있기 때문에 더욱 심해질 수 있습니다..

SQL 삽입 공격 방지

이전에 여러 번 언급했듯이 SQL 주입 공격은 쉽게 예방할 수 있습니다. 웹 개발의 기본 규칙 중 하나는 위의 템플릿 쿼리에서 간단한 대체를 수행했을 때와 마찬가지로 사용자 입력을 맹목적으로 신뢰하지 않는 것입니다.

SQLI 공격은 입력을 위생적으로 (또는 이스케이프 처리하여) 소위 말하는 것에 의해 쉽게 저지됩니다. sanitize 프로세스는 사실 아주 사소한데 그 이유는 모든 인라인 작은 따옴표 ( ') 문자를 처리하여 SQL 문 내부의 문자열을 조기에 종료하는 데 사용할 수 없기 때문입니다.

예를 들어 데이터베이스에서 "O'neil"을 조회하려면 O 뒤에 작은 따옴표를 붙이면 문자열이 조기에 끝나기 때문에 간단한 대체를 사용할 수 없습니다. 대신 해당 데이터베이스의 이스케이프 문자를 사용하여 위생을 방지 할 수 있습니다. 인라인 작은 따옴표의 이스케이프 문자가 각 따옴표 앞에 \ 기호로 시작한다고 가정 해 봅시다. 따라서 "O'neal"은 "O \ 'neil"으로 소독 될 것입니다..

이 간단한 위생 행위는 SQLI 공격을 막아줍니다. 예를 들어 이전 예제를 다시 살펴보고 사용자 입력이 삭제되었을 때 결과 쿼리를 봅시다.

myuser '-- / 그릇된 길:

SELECT UserID from Users WHERE UserName = "myuser \"- 'AND Password = "wrongpass"

myuser 다음의 작은 따옴표가 이스케이프 처리되므로 (대상 값의 일부로 간주 됨) 데이터베이스는 문자 그대로 UserName을 검색합니다. "myuser"- ". 또한 대시는 SQL 문 자체가 아닌 문자열 값에 포함되므로 SQL 주석으로 해석되는 대신 대상 값의 일부로 간주됩니다.

로버트 '; DROP TABLE 사용자;-- / 그릇된 길:

사용자 ID에서 SELECT 사용자 ID WHERE UserName = "Robert \"; DROP TABLE 사용자; - 'AND 암호 = "wrongpass"

Robert 다음에 작은 따옴표를 이스케이프 처리하면 사용자 이름 검색 문자열에 세미콜론과 대시가 모두 포함되므로 데이터베이스에서 문자 그대로 검색합니다 "Robert"; 사용자 테이블 삭제 - "" 테이블 삭제를 실행하는 대신.

요약하자면

웹 공격이 진화하고보다 정교 해지거나 다른 진입 지점에 집중하는 동안 공격을 위해 고안된 여러 가지 무료 해커 도구의 영감을 얻은 진정한 공격으로부터 보호하는 것을 기억하는 것이 중요합니다.

DDoS와 같은 특정 유형의 공격은 쉽게 피할 수 없지만 SQLI와 같은 다른 공격은 피할 수 있습니다. 그러나 이러한 유형의 공격으로 인해 발생할 수있는 손상은 취할 수있는 예방 조치에 따라 불편 함에서 파국까지 다양합니다..