WEB 프런트엔드의 일반적인 공격 방식 및 해결 방법 요약

한 사이트가 구축된 후에 안전 문제에 주의하지 않으면 공격을 받기 쉽다. 다음은 몇 가지 빈틈 상황과 공격을 방지하는 방법을 토론한다.
1. SQL 주입
SQL 주입이란 웹 폼에 SQL 명령을 삽입하여 도메인 이름이나 페이지가 요청한 검색 문자열을 제출하거나 입력함으로써 서버를 속여 악의적인 SQL 명령을 실행하는 것이다.구체적으로 말하면 기존 응용 프로그램을 이용하여 (악의적인) SQL 명령을 백그라운드 데이터베이스 엔진에 주입하여 실행하는 능력이다. 웹 폼에 SQL 문장을 입력하여 보안 결함이 있는 사이트의 데이터베이스를 얻을 수 있으며, 디자이너의 의도에 따라 SQL 문장을 실행하는 것이 아니다.예를 들어 이전의 많은 영화와 드라마 사이트에서 VIP 회원 비밀번호를 누설한 것은 대부분 WEB 폼을 통해 조회 문자를 전달하는 것이다. 이런 폼은 특히 SQL 주입식 공격을 받기 쉽다.
원리:
SQL 주입 공격이란 특수한 입력을 구축하여 매개 변수로 웹 응용 프로그램에 전송하는 것을 말한다. 이런 입력은 대부분 SQL 문법의 일부 조합으로 SQL 문장을 실행하고 공격자가 필요로 하는 조작을 집행한다. 그 주요 원인은 프로그램이 사용자가 입력한 데이터를 세밀하게 필터하지 않아 불법 데이터가 시스템에 침입하기 때문이다.
관련 기술 원리에 따라 SQL 주입은 플랫폼 층 주입과 코드 층 주입으로 나눌 수 있다.전자는 안전하지 않은 데이터베이스 설정이나 데이터베이스 플랫폼의 빈틈으로 인해 발생한다.후자는 주로 프로그래머가 입력에 대해 세밀하게 필터를 하지 않았기 때문에 불법 데이터 조회를 집행했다.이를 바탕으로 SQL 주입의 발생 원인은 일반적으로 다음과 같은 몇 가지 측면에 나타난다.
① 부적절한 유형 처리;
② 안전하지 않은 데이터베이스 구성;
③ 불합리한 조회집 처리;
④ 잘못된 처리;
⑤ 이스케이프 문자 처리가 부적합합니다.
⑥ 여러 개의 제출 처리가 부적절하다.
보호:
　　1.사용자의 입력을 영원히 신뢰하지 마세요.사용자의 입력을 교정하고 정규 표현식을 통해 길이를 제한할 수 있다.따옴표와 이중 "-"를 변환합니다.
　　2.동적 패키지 sql를 영원히 사용하지 마십시오. 매개 변수화된 sql를 사용하거나 저장 프로세스를 직접 사용하여 데이터 조회 접근을 할 수 있습니다.
　　3.관리자 권한의 데이터베이스 연결을 영원히 사용하지 마십시오. 모든 응용 프로그램에 단독 권한이 제한된 데이터베이스 연결을 사용하십시오.
　　4.기밀 정보를 직접 저장하거나 암호화하거나hash로 암호와 민감한 정보를 떨어뜨리지 마세요.
　　5.응용된 이상 정보는 가능한 한 적은 힌트를 주어야 하며, 사용자 정의 오류 정보를 사용하여 원시 오류 정보를 포장하는 것이 가장 좋다
　　6.ql 주입의 검측 방법은 일반적으로 보조 소프트웨어나 사이트 플랫폼을 이용하여 검측하고 소프트웨어는 일반적으로 ql 주입 검측 도구 jsky, MDCSOFT SCAN 등을 사용한다.DCSOFT-IPS를 사용하면 SQL 주입, XSS 공격 등을 효과적으로 방어할 수 있습니다.
2. 크로스 스크립트 공격(XSS, Cross-site scripting)
크로스 스크립트 공격(XSS)은 가장 흔하고 기본적인 웹 사이트를 공격하는 방법이다.공격자는 웹 페이지에 공격적인 코드를 포함하는 데이터를 발표한다.브라우저가 이 페이지를 볼 때, 특정한 스크립트는 브라우저 사용자의 신분과 권한으로 실행됩니다.XSS를 통해 사용자 데이터를 비교적 쉽게 수정하고 사용자 정보를 훔치며 CSRF 공격과 같은 다른 유형의 공격을 일으킬 수 있다.
일반적인 해결 방법: HTML 페이지로 출력된 데이터가 HTML로 변환되는지 확인합니다.
잘못된 페이지의 빈틈도 XSS 공격을 초래할 수 있습니다. 예를 들어 페이지/gift/giftList입니다.htm?페이지=2 찾을 수 없습니다.오류 페이지는 이 URL을 그대로 출력합니다. 만약 공격자가 URL 뒤에 공격 코드를 붙여서 피해자에게 보내면 XSS 공격이 발생할 수 있습니다
3. 크로스 스테이션 요청 위조 공격(CSRF)
크로스 사이트 요청 위조(CSRF, Cross-site request forgery)는 또 다른 흔한 공격이다.공격자는 각종 방법을 통해 요청을 위조하고 사용자가 표를 제출하는 행위를 모방하여 사용자의 데이터를 수정하거나 특정 임무를 수행하는 목적을 달성한다.가짜 사용자의 신분을 위해 CSRF 공격은 XSS 공격과 자주 협조하지만 다른 수단을 통해 예를 들어 사용자가 공격을 포함하는 링크를 클릭하도록 유도할 수도 있다.
해결의 방향은 다음과 같다.
　　1.POST 요청으로 공격의 난이도를 증가시킵니다.사용자가 링크를 클릭하면 GET 유형의 요청을 시작할 수 있습니다.반면에 POST 요청은 상대적으로 어렵다. 공격자는 자바스크립트를 빌려야만 실현할 수 있다
　　2.요청에 대해 인증을 하고 이 요청이 사용자 본인이 표를 작성하여 제출한 것이지 제3자가 위조한 것이 아니라는 것을 확보한다.구체적으로 세션에 token을 추가하여 정보를 보고 제출한 사람이 같은 사람인지 확보할 수 있다
4. Http Heads 공격
브라우저로 어떤 웹 사이트를 보든지 당신의 웹 사이트가 어떤 기술과 프레임워크를 사용하든지 간에 HTTP 프로토콜을 사용합니다.HTTP 프로토콜은 Response header와 content 사이에 두 개의 CRLF(0x0D 0A) 문자가 비어 있습니다.이 공행은 헤더의 끝과 콘텐츠의 시작을 상징합니다.총명한 공격자는 이 점을 이용할 수 있다.공격자가 임의의 문자를 헤더에 주입하는 방법이 있다면 이런 공격은 발생할 수 있다.
로그인을 예로 들면: 다음과 같은 URL이 있습니다.http://localhost/login?page=http%3A%2F%2Flocalhost%2Findex
로그인이 성공하면 페이지 매개 변수가 지정한 페이지로 되돌아가야 합니다.다음은 리셋이 발생할 때의response 헤더입니다.

HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/index

URL을 수정하면 다음과 같이 됩니다.
　　http://localhost/login?page=http%3A%2F%2Flocalhost%2Fcheckout%0D%0A%0D%0A%3Cscript%3Ealert%28%27hello%27%29%3C%2Fscript%3E
그러면 리셋이 발생할 때의 리셋은 아래의 모습으로 바뀝니다.

HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/checkout<CRLF>
<CRLF>
<script>alert('hello')</script>

이 페이지는 URL에 숨겨진javascript를 의외로 실행할 수 있습니다.유사한 상황은 위치 헤더뿐만 아니라 Set-Cookie 헤더와 같은 다른 헤더에서도 발생할 수 있다.이런 공격이 성공하면 스크립트 실행, 추가 쿠키 설정(Set-Cookie:evil=value) 등 많은 일을 할 수 있다.
이런 공격을 피하는 방법은 모든response 헤더를 필터해서 헤더에 나타나는 불법 문자, 특히 CRLF를 제거하는 것이다.
서버는 일반적으로request headers의 크기를 제한합니다.예를 들어 아파치 서버의 기본 제한 리퀘스트 헤더는 8K입니다.8K를 초과하면 Aapche Server에서 400 Bad Request 응답을 반환합니다.
대부분의 경우 8K는 충분히 크다.응용 프로그램이 사용자가 입력한 내용을 쿠키에 저장한다고 가정하면 8K를 초과할 수 있습니다.공격자는 8k가 넘는 헤더 링크를 피해자에게 보내면 서버에 접근이 거부됩니다.해결 방법은 쿠키의 크기를 검사하고 새로운 쿠키의 총 대문자를 제한하며 헤더가 너무 커서 발생하는 접근 거부 공격을 줄이는 것이다.
5. 쿠키 공격
JavaScript를 통해 현재 웹 사이트의 쿠키에 쉽게 액세스할 수 있습니다.모든 사이트를 열고 브라우저 주소 표시줄에 입력할 수 있습니다:javascript:alert (doucment.cookie). 현재 사이트의 쿠키를 바로 볼 수 있습니다.공격자는 이 특성을 이용하여 당신의 관건적인 정보를 얻을 수 있습니다.예를 들어 XSS 공격과 결합하여 공격자는 브라우저에서 특정한 자바스크립트 스크립트를 실행하여 쿠키를 얻습니다.만약 이 사이트가 쿠키에만 의존하여 사용자의 신분을 검증한다면 공격자는 당신의 신분을 사칭하여 일을 할 수 있다.
현재 대부분의 브라우저는 쿠키에 HttpOnly 표시를 지원합니다. 이 표시가 있는 쿠키는 자바스크립트를 통해 얻을 수 없습니다. 관건적인 쿠키에 이 표시를 하면 쿠키의 안전성을 크게 향상시킬 수 있습니다.
6. 리디렉션 공격
자주 사용하는 공격 수단은 낚시다.낚시 공격자는 일반적으로 피해자에게 합법적인 링크를 보내는데 링크가 눌렸을 때 사용자는 그럴듯하지만 그렇지 않은 불법 사이트를 안내하여 사용자의 신뢰를 사취하고 사용자 자료를 훔치는 목적을 달성한다.이런 행위를 방지하기 위해서, 우리는 위험한 곳으로 방향을 바꾸는 것을 피하기 위해 모든 방향을 조정해야 한다.흔히 볼 수 있는 해결 방안은 화이트리스트입니다. 합법적으로 방향을 바꿀 URL을 화이트리스트에 추가하고, 화이트리스트의 도메인 이름이 방향을 바꿀 때 거부합니다.두 번째 해결 방안은 토큰을 재정립하는 것이다. 합법적인 URL에 토큰을 추가하고 방향을 재정립할 때 검증한다.
7. 파일 업로드 공격
　　1.파일 이름 공격, 업로드된 파일은 업로드하기 전의 파일 이름을 사용합니다. 클라이언트와 서버 문자 코드가 호환되지 않아 파일 이름이 혼란스러워질 수 있습니다.파일 이름에 스크립트가 포함되어 공격을 일으킵니다.
　　2.파일 접두사 공격, 업로드된 파일의 접두사는 exe 실행 가능한 프로그램, js 스크립트 등 파일일 수 있습니다. 이 프로그램은 피해자의 클라이언트, 심지어 서버에서 실행될 수 있습니다.따라서 허가되지 않은 파일 이름 접두사를 제외하기 위해 파일 이름 접두사를 필터해야 합니다.
　　3.파일 내용 공격, IE6는 서버가 보내는content type을 신뢰하지 않고 자동으로 파일 내용에 따라 파일의 유형을 식별하고 식별된 유형에 따라 파일을 표시하거나 실행하는 심각한 문제가 있습니다.gif 파일을 업로드하면 파일 끝에 js 공격 스크립트를 넣으면 실행될 수 있습니다.이러한 공격은 파일 이름과 콘텐츠 type이 모두 합법적인gif 그림으로 보이지만 그 내용은 스크립트를 포함하고 있습니다. 이러한 공격은 파일 이름으로 필터할 수 없고 파일 내용을 스캔해야만 식별할 수 있습니다.
이상은 WEB 전단에서 흔히 볼 수 있는 공격 방식과 해결 방법에 대한 상세한 내용입니다. 웹 전단의 공격 및 해결 방법에 대한 더 많은 자료는 저희 기타 관련 글을 주목해 주십시오!