XSS 취약점이란??
1. SQL injection 과 함께 웹 상에서 가장 기초적인 취약점 공격 방법의 일종으로 , 악의적인 사용자가 공격하려는 사이트에 스크립트를 넣는 기법을 말한다.
공격에 성공하면 , 사이트에 접속한 사용자는 삽입된 코드를 실행 하게 되며 , 보통 의도치 않은 행동을 수행시키거나 쿠키나 세션 토큰 등 의 민감한 정보를 탈취한다.
2. 기본적인 수준에서 XSS 공격은 공격자가 웹 양식 or 웹 앱 URL에 악성코드를 주입해 애플리케이션이 본래 애플리케이션의 의도와 다른 특정 작업을 실행하도록 유도하는 것이다.
3. 크로스 사이트 스크립팅이란 자바스크립트를 사용하여 공격하는 경우가 많다.
4. 공격 방법이 단순하고 가장 기초적이지만 , 많은 웹사이트들이 XSS에 대한 방어 조치를 해두지 않아 공격을 받는 경우가 많다
5. 여러 사용자가 접근 가능한 게시판 등에 코드를 삽입하는 경우도 많으며 , 경우에 따라서는 메일과 같은 매체를 통해서도 전파된다
6. XSS 결함은 애플리케이션에서 새 웹 페이지가 적절한 검증 또는 회피 없이 신뢰할 수 없는 데이터를 포함하거나 , HTML 또는 자바스크립트를 생성할 수 있는 브라우저 API를 사용해 사용자가 입력한 데이터로 기존 웹 페이지를 업데이트할 때 발생한다.
7. XSS는 공격자가 피해자의 브라우저에서 스크립트를 실행해 사용자 세션을 하이재킹하고 , 웹 사이트를 훼손하거나 사용자를 악성 사이트로 리다이렉션할 수 있게 해준다.
8. 웹 페이지 생성 중 부적절한 입력 무력화
XSS 공격의 개요
1. 웹 애플리케이션이 사용자를 인증하는 방법
è 가장 먼저 아이디와 패스워드를 기반으로 사용자의 신원 확인
è 신원 확인 후 웹 애플리케이션이 사용자에게 고유한 값을 전달
è 그 이후부터 사용자는 웹 애플리케이션으로부터 받은 고유한 값을 가지고 사이트 이용
XSS 예시
è 해커의 홈페이지에 PHP 파일을 만들고 , 공격할 사이트에 스크립트를 심은 뒤 , 사용자가 스크립트가 심어진 페이지를 볼 경우 , 쿠키값이 해커의 홈페이지로 넘어가서 세션 하이재킹이 가능해진다.
쿠키란 ??
1. 사용자가 인터넷 웹 사이트에 방문할 때 생기는 4KB 이하의 파일
2. 쿠키 내용을 이용하여 클라이언트의 신분을 알 수 있다.
3. 많은 웹 사이트는 쿠키를 이용하여 사용자 정보를 수집
쿠키의 사용
1. 사용자 컴퓨터에 쿠키 생성
2. 사용자 컴퓨터의 쿠키를 웹 서버로 전송
쿠키의 용도
1. 사이트 개인화
è 쿠키를 이용하면 아이디와 비밀번호 외에도 사용자의 ‘성향’까지 파악 가능
è 사용자의 성향을 고려한 개인 맞춤 서비스를 마련한다면 , 다른 사이트와 중요한 차별점이 될 수 있다.
2. 장바구니 시스템
è 사용자가 고른 물건을 쿠키에 저장
3. 웹 사이트 이용 방식 추적
è 사용자들의 사이트 방문 유형을 파악하여 마케팅 정보로 활용
4. 타깃 마케팅
è 광고주가 대형 포털 사이트의 광고 공간을 사들여 자회사의 광고를 사용자에게 보여주는 것 ( 더블클릭이 대표적이다 )
è 광고를 낸 업체들이 광고 효과가 궁금해하기 때문에 광고 대행업체는 제3의 업체의 쿠키를 사용자 컴퓨터에 저장해 사용자 이용 정보를 수집한다.
쿠키에 관한 오해
1. 쿠키가 바이러스를 전파한다??
è 쿠키는 텍스트 파일이기 때문에 ‘실행’되지 않아 바이러스를 전파할 수 없다.
2. 쿠키가 사용자 컴퓨터에 피해를 입힌다??
è 사이트에서 만든 특정 데이터만 있을 뿐 , 어떠한 정보도 담겨 있지 않다.
è 스스로 디렉터리를 읽거나 파일을 지우는 작업도 절대 수행 불가능 하다
쿠키
1. 쿠키의 특징은 소프트웨어가 아니므로 프로그램처럼 실행될 수 없으며 , 바이러스를 옮기거나 악성코드를 설치할 수도 없다
2. 하지만 스파이웨어를 통해서 사용자의 브라우징 행동을 추적하거나 , 다른 사람의 쿠키를 훔쳐서 웹계정 접근권한을 획득할 수도 있다.
3. 웹사이트마다 다르지만 , 허술한 웹사이트에서는 계정정보나 중요한 정보등을 쿠키로 담고 있는 곳도 있다.
XSS ( Cross – site – script )
1. 다른 사용자의 정보를 추출하는 공격 기법으로 , 입력을 받아들이는 부분의 스크립트 코드를 필터링하지 않음으로써 공격자가 스크립트 코드를 실행할 수 있다.
2. 예를 들어서 보자 . 공격자가 악성코드를 취약한 웹 서버에 삽입을 한다 . 그리고 나서 사용자가 취약한 웹 서버를 통해서 게시물을 방문할 것이다 . 그러면 그 때 악성 스크립트 가 실행이 되면서 , 쿠기 정보가 공격자에게 노출이 되는 것이다 .
XSS의 유형
1. XSS 공격은 서로 다소 겹치는 부분이 있는 세 가지 요소로 구성된다.
2. 반사된 XSS ( 지속이지 않다 )
3. 저장된 XSS (sotred XSS , 지속적이다 )
4. 문서 객체 모델 ( document object model , DOM ) 기반
Reflected XSS
1. URL의 변수 부분처럼 스크립트 코드를 입력하는 동시에 결과가 바로 전해지는 공격 기법
2. 반사된 XSS는 피싱 공격의 일부로 자주 사용되며 악용하기도 , 차단하기도 가장 쉽다
3. <script> alert(“I “ m inwoo kim “) </script>
4. 위의 스크립트는 반사된 XSS의 가장 기본적인 예이다.
5. 공격자가 HTTP 요청에 악성 콘텐츠를 주입하면 그 결과가 사용자에게 “반사되는”형태이다.
6. 물론 , 공격자가 자기 자신을 악용하고자 할 가능성은 별로 없지만 , 링크를 클릭하도록 피해자를 속이고 , 유인해 세션을 하이재킹할 수 있다.
7. 따라서 반사된 XSS는 피싱 공격에서 흔히 사용된다.
8. 예를 들어서 공격자는 취약한 웹 애플리케이션을 악용하는 악성 URL을 만든 다음 피싱이나 기타 소셜 엔지니어링 기법을 사용해서 웹 애플리케이션 사용자를 유인 , 악성 링크를 클릭하도록 할 수 있다.
9. 웹 애플리케이션은 악성코드를 피해자에게 반사해 피해자의 웹 브라우저에서 악성코드를 실행할 수 있다.
Stored XSS
1. 가장 일반적인 XSS 공격 유형
2. 사용자가 글을 저장하는 부분에 정상적인 평문이 아닌 스크립트 코드를 입력한다.
3. 다른 사용자가 게시물을 열람하면 공격자가 입력해둔 악성 스크립트가 실행되어 사용자의 쿠키 정보가 유출되거나 악성 스크립트가 기획한 공격에 속수무책으로 당하게 된다.
4. 저장된 혹은 지속적 XSS 공격은 공격자가 웹 애플리케이션을 속여 웹 애플리케이션 데이터베이스에 악성코드를 저장하도록 하는 수법이다. 서버에 저장된 악성 코드는 시스템 자체를 공격할 수 있고 , 웹 앱 사용자 상당수 , 또는 전체에 악성코드를 전송할 수 있게 된다.
5. 일반적인 예는 블로그 댓글에 악성코드를 게시하는 것이다
Ex)
<script> alert(“I m inwoo kim attack “) </script>
6. 해당 블로그를 방문하는 사람은 누구나 악성코드의 피해자가 된다.
7. 따라서 지속적 XSS는 가장 위험한 XSS 공격 유형이다.
문서 객체 모델 ( document object model , DOM ) 기반 XSS
1. 가장 새로운 XSS 공격 유형은 DOM 기반 공격이다
2. 반사 또는 저장된 XSS와 달리 DOM 기반 XSS는 웹 애플리케이션 서버측이 아닌 클라이언트 측 코드를 공격하며 , 그 대상은 자바스크립트인 경우가 많고 피해자의 브라우저에서 악성코드를 실행한다.
예제를 통한 XSS 이해
게시자가 글을 보면 자신의 쿠키가 창으로 나오게 해보는 예제
1. 먼저 글을 작성한다. 이때 제목은 많은 사람들이 볼 수 있게끔 최대한 자극적으로 정한다
2. script문을 작성하는데 , alert 메시지가 뜨게한다.
3. 쿠키의 정보를 떠버리게 하겠습니다 라는 의미정도.
위의 그림처럼 cookie 정보가 나오게 된다.
이렇게 글을 읽는 사람( Client ) 의 쿠키 값이 나오게 된다.
이것을 수정하면 , 읽는 사람의 쿠키 값을 공격자에게 보내지게 되어 공격자는 글을 읽는 클라이언트들의 쿠키 값을 수집할 수도 있게 된다.
추가적으로 XSS 취약점 찾는 방법
1. XSS 취약점 찾는 방법이다.
è 표준 스크립트 문자열을 입력해 보는 것이다
<script> alert(document.cookie)</script>
2. 스크립트 검증 예시로 사용되는 코드들
"><script>alert(document.cookie)</script>
"><ScRiPt>alert(document.cookie)</ScRiPt>
"%3e%3cscript%3ealert(document.cookie)%3c/script%3e
"><scr<script>ipt>alert(document.cookie)</scr</script>ipt>
%00"><script>alert(document.cookie)</script>
그 밖의 XSS 공격 ( CSRF 공격 )
1. 크로스 사이트 요청 변조 공격
2. 사이트간 요청 위조 ( Cross – Site request forgery )
è 피해자가 인지하지 못하는 상태에서 피해자의 브라우저가 특정 사이트에 강제적으로 리퀘스트를 보내도록 하는 기법
è 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위 ( 수정 , 삭제 , 등록 등 ) 를 특정 웹사이트에 요청하게하는 공격
CSRF 공격의 원리를 보면 다음과 같다.
공격자가 취약한 웹 서버에 악성 코드를 삽입한다 .
사용자가 취약한 웹 서버에 게시물 방문을 한다 .
악성 스크립트에 의한 액션이 발생한다.
개인정보 수정 , 회원 탈퇴 , 임의의 행동을 수행하게 되는 것이다 .
CSRF 를 통해서 해커는 희생자의 권한을 도용하여 중요 기능을 실행하는 것이 가능하다 .
예를 들어서 , 페이스북에 희생자의 계정으로 광고성 글을 올리는 것이 가능해 진다.
CSRF는 해커가 사용자의 컴퓨터를 감염시키거나 페이스북 서버를 해킹을 해서 이뤄지는 공격이 아니다.
그래서 CSRF 공격이 이뤄지려면 다음 조건이 만족되어야 한다 .
ㄱ. 위조 요청을 전송하는 서비스에 희생자가 로그인 상태
ㄴ. 희생자가 해커가 만든 피싱 사이트에 접속
l 희생자가 해커가 만든 피싱 사이트를 하지 않더라도 해커가 XSS 공격을 성공한 정상 사이트를 통해서 CSRF 공격이 수행될 수 도 있다.
페이스 북에 글을 쓸 때 아래 코드와 같은 폼이 전송된다고 예를 들어 보자 .
피싱 사이트에 똑같이 페이스 북에 글쓰기를 요청하는 폼이 숨겨져 있고 , 그 내용으로 가입하면 10만원을 준다는 사기성 광고를 본문으로 적혀져 있다 . 희생자는 피싱 사이트에 접속함으로써 본인의 페이스북 계정으로 해당 글이 등록되게 된다.
CSRF의 방어 기법
대표적으로 다음 2가지 방어 기법이 있다 .
1. Referrer 검증
2. Security Token 사용
è 일반적으로 CSRF 공격 방어는 조회성 ( HTTP GET Method ) 데이터에는 방어 대상에 두지 않고 , 쓰기 / 변경이 가능한 POST , PATCH , DELETE Method에만 적용하면 된다 .
è 물론 정말 중요한 데이터를 조회하거나 GET을 통해 쓰기/변경 등의 동작을 한다면 GET Method에도 방어를 해야할 수도 있다 .
Referrer 검증이란 무엇인가 ?
Back-end 단에서 request 의 referrer를 확인하여 domain이 일치하는 지 검증하는 방법
Referrer 검증만으로 대부분의 CSRF 공격을 방어할 수 있지만 , 같은 도메인 내의 페이지에 XSS 취약점이 있는 경우 CSRF 공격에 취약해질 수 있다.
Domain 단위 검증에서 좀 더 세밀하게 페이지 단위까지 일치하는지 검증을 하면 도메인 내의 타 페이지에서의 XSS 취약점에 의한 CSRF 공격을 방어할 수 있다 .
Security Token 사용은 무엇인가 ??
Referrer 검증이 불가한 환경이라면 , Security Token를 활용할 수 있다.
우선 사용자의 세션에 임의의 난수 값을 저장하고 , 사용자의 요청 마다 해당 난수 값을 포함 시켜 전송한다.
이후 Back-end 단에서 요청을 받을 때마다 세션에 저장된 토큰 값과 요청 파라미터에 전달되는 토큰 값이 일치하는 지 검증하는 방법
이 방법도 결국 같은 도메인 내에 XSS 취약점이 있다면 CSRF 공격에 취약해 진다.
XSS 와 CSRF의 차이점
XSS 공격과 CSRF ( Cross-site request forgery ) 는 피해자의 브라우저를 목표로 하는 비슷한 공격이다.
가장 큰 차이점은 CSRF 는 사용자의 인증된 세션을 악용하며 , XSS 는 인증된 세션이 없어도 공격 효과를 거둘 수 있다는 점이다.
XSS는 자바스크립트를 실행시키는 것이고 , CSRF는 특정한 행동을 시키는 것이므로 다르다 .
XSS의 방지 대책
1. 쿠키에 중요한 정보를 담지 않고 서버에 중요정보를 저장하는 방법
2. 또한 정보를 암호화 하는 것도 또 하나의 방법이다.
3. XSS의 방지대첵
è 특정 패턴을 만든다 : 악의적인 사이트를 못 들어가게 한다.
è Html의 태그를 지정된 태그를 제외하고는 모두 막아 버린다
è 쿠키를 저장할 때 , 쿠키 값을 랜덤으로 저장하게 하거나 인증 불가 , 중요정보를 쿠키에 저장 못하게 한다.
Dos 공격의 분류
l ‘정상적인 세션 연결’여부에 따라 분류할 수 있다.
1. 정상적인 세션 연결을 고려하지 않은 DDos 공격
è 전통적인 Dos /DDos 공격은 많은 트래픽을 유발함으로써 서비스를 제공하는 서버의 과부하를 일으키는 기법을 사용한다.
è 이는 일반적인 인터넷 환경에서 생성될 수 있는 여러 가지 프로토콜을 기반으로 하여 네트워크 입장에서는 정상적으로 보이는 패킷을 과도하게 발생함으로써 서비스의 과부하를 일으켜 서비스 거부 공격을 수행하게 되는 것이다.
è 이러한 유형에는 인터넷 환경에서 가장 많이 사용하는 TCP 프로토콜을 이용하는 기법과 TCP 프로토콜이 아닌 UDP/ICMP 프로토콜 기법의 DDos 공격 유형이 존재한다
ㄱ. TCP 프로토콜을 이용한 Flooding Attack
è TCP Syn Flooding
ㄴ. TCP 프로토콜 이외의 UDP/ICMP 프로토콜을 이용한 Flooding
ㄷ. 잘못된 프로토콜 헤더를 이용한 Flooding
2. 정상적인 세션 연결 기반의 DDos 공격
è 정상적인 세션을 정상적으로 연결하기 때문에 전통적으로 사용하는 보안 젶ㅜㅁ의 본연의 기능 및 정상 세션 검증 절차를 쉽게 회피할 수 있따.
è 또한 공격이 집중되는 서버 입장에서는 정상적인 세션 처리까지 수행해야 하기 때문에 단순한 Flooding 공격보다 더 많은 서비스의 부하를 일으킨다.
è 정상적인 세션 연결 기반의 DDos 공격 종류
ㄱ. TCP Connection Flooding
ㄴ. HTTP Get Flooding
ㄷ. HTTP CC Attack
ㄹ. Dynamic HTTP Request Flooding
ㅁ. HTTP 취약점 기반 DDos Attack
Dos 공격
1. 7계층 Dos 공격
3,4 계층 Dos 공격과 7계층 Dos 공격의 차이
3,4계층 Dos 공격
ㄱ. 대역폭 고갈 공격
ㄴ. 세션 고갈 공격
ㄷ. TCP , UDP , ICMP
ㄹ. 단순한 Flooding 형태의 트래픽을 대량으로 발생시켜 공격
ㅁ. Spoofed IP로 비정상적인 트래픽을 이용한 공격의 비율이 높다
ㅂ. 보안 장비를 통해 방어 가능하다
7계층 Dos 공격
ㄱ. 서버의 자원 고갈 공격
ㄴ. HTTP , SMTP , FTP , VoIP 등
ㄷ. 정상 트래픽을 이용한 공격
ㄹ. 소량의 트래픽을 이용한 공격
ㅁ. 특정 어플리케이션의 취약점을 이용한 공격
2. 7계층 공격의 주요 특징
è 정상적인 TCP/UDP 연결 기반의 공격으로 , 변조된 IP가 아닌 정상 IP를 이용한 접속 요청 후 공격이 진행되어 정상 사용자의 트래픽과 구분하기가 어려워 탐지가 어렵다 .
è 소량의 트래픽을 이용한 공격으로 오랜 시간에 걸쳐 서서히 공격이 진행되어 탐지가 어렵다
è 특정 서비스의 취약점을 이용하여 공격 한다 .
3. HTTP GET Flooding 공격 ( HTTP GET 요청을 다량으로 발생시키는 공격 )
è 공격 대상 시스템에 TCP 쓰리웨이 핸드셰이킹 과정을 통해 정상적으로 접속한 뒤 , HTTP 의 GET Method를 통해 특정 페이지를 무한대로 실행하는 방식
è 웹 서버에 대한 대량의 조회를 통해서 서버에 과부하를 주는 방식
è GET : 단순히 보기용 , POST : DB 내용을 수정시킨다
HTTP GET Flooding 공격 시나리오
è 공격자는 웹서버가 운영하고 있는 지 확인하는 스캐닝 공격을 진행한 뒤 운영 중이라면 웹서버의 웹 파일(html)에 다수의 GET 메소드 요청을 보내어 웹서버가 서비스를 제대로 운용할 수 없도록 한다 .
4. HTTP CC 공격
è HTTP GET Flooding with Cache Control Attack ( CC Attack )
è Dos 공격 기법에 ‘Cache-Control : no-store , must-revalidate’ 옵션을 사용하면 , 웹 서버는 캐시를 사용하지 않고 응답을 해야 하므로 웹 서비스의 부하가 증가하게 된다 .
è 웹 서버의 부하를 감소시키기 위해 공격자는 HTTP 캐시 옵션을 조작하여 웹서버의 자원을 소진시키는 서비스 거부 공격이다 .
è 쉽게 말해서 , 캐시 없기 때문에 , 일일이 찾아서 해야 하기 때문에 서버의 부하가 생길 것이다.
è 웹 서비스가 빠르게 안될 수도 있다.
è Cache-Control: no-cache : 한줄만 적어 주었다 , no-cache 때문에 Response 할 때 좀 더 많은 시간이 필요할 것이다 .
5. Slow HTTP Header Dos ( Slowloris ) 공격
è 서버로 전달할 HTTP 메시지의 Header 정보를 비정상적으로 조작하여 웹 서버가 헤더 정보를 완전히 수신할 때까지 연결을 유지하도록 하여 시스템 자원을 소비시켜 다른 클라이언트의 정상적인 서비스를 방해하는 공격이다.
è 불안전한 메시지를 수신한 웹 서버는 클라이언트의 요청이 끝나지 않은 것으로 인식하여 웹 로그를 기록하지 않는다 .
è 데이터 앞에 붙는 header의 길이를 절반으로 잘라서 보낸다 . Header를 받고 데이터 받고 tail를 가지고 첨삭을 하게 된다 . ( 확인을 하게 되는 것이다)
è 그런데 잘라서 가게 되면 , 기다리게 될 것이다 .
è 이 반복 잡업을 하게 되면 , Header 절반을 기다리는 이 작업을 못기다리게 된다 à 요청이 끝나지 않은 것으로 인식하여 웹 로그를 기록하지 않는다.
è 디도스를 탐지하는 보안장비의 경우 정책설정 기준이 대부분 ‘pps/제한시간’ 이다
(pps : packet per second )
평균 규입 pps로 임계값을 정하고 , 패턴을 통해 초당 유입하는 pps로 정책 임계값을 설정한 후 , 임계값 이상으로 트래픽이 들어오면 이벤트 로그가 뜨고 이를 바탕으로 차단이 이루어지는 형태이다.
그러나 slowloris 처럼 저대역폭으로 보내면 임계치에 걸리지 않기 때문에 보안장비를 무사통과할 가능성이 높아진다.
공격방법
è 공격자는 공격 대상 서버로 접속하여 정상 세션을 맺은 후에 비정상적인 헤더 값을 서버로 요청하여 open connection을 유지한다.
정상헤더는 “0d0a(CRLF)”로 완료되지만 , slowloris attack은 “0d”의 비정상 헤더값을 전송한다.
결국에는 , 서버에서는 헤더의 전송이 완료되지 않는 것으로 판단하고 계속해서 connection 을 유지한다.
Ex )
세션이 연결된 뒤 GET 요청을 보낸다 à 완전하지 않는 요청을 보냄으로써 open connection 유지 한다 à 서버는 헤더를 기다리게 된다 à 서버는 연결양에 따라 Dos 상태가 된다 à 요청의 헤더끝이 [ 0d0a0d0a ] 로 끝나지 않는다 .
WAF ( Web application firewall ) 에서의 대응방법
1. WAF가 가지고 있는 Session timeout값을 이용하여 특정시간 이상 열려있는 세션을 종료시킨다 . ( default : 60초 )
2. WAF에서 요구하는 헤더의 Entity 가 포함되어 있지 않을 경우 차단 시킨다 .
6. Slow HTTP POST 공격
è 웹 서버와의 커넥션을 최대한 장시간 동안 유지하여 웹 서버가 정상적인 이용자의 접속을 받아들일 수 없게 하는 방식
è 필요로 하는 Content-Length를 설정하면 slow HTTP POST 공격을 어느 정도 대응 가능하다
è 이 공격은 RUDY 공격이라 한다 .
RUDY / R-U-DEAD-YET ( RUDY ) : http를 이용한 일종의 Dos 공격이다.
http의 특성 중 하나인 상태정보를 유지하지 않는 것을 이용
이를 강제로 지속하기 위해 지연시키는 공격이다.
HTTP POST method는 기본적으로 content-length 값을 이용하여 데이터공간을 확보 후 HTTP request 하는 것이다 .
이 때 수신을 할 때 수용하는 데이터를 1byte 단위로 처리하도록 한다.
긴 데이터를 segmentation 하여 HTTP로 전송하는 방식으로 서비스 거부를 유발한다
공격은 Console을 통해 이루어지며 POST Method를 이용하여 설정 파일에 기록된 URL을 대상으로 공격을 수행한다.
많은 데이터를 보낼 것이라고 이야기 해놓고 정작 1byte 단위로 발송하고 , 이렇게 되면 그 event를 처리하는 서버 측은 부하가 발생하게 되는 것이다.
이와 비슷한 공격 유형으로써 HTTP Slow Read Attack 이 있다.
요청 받게 되는 대용량요청을 read시 1byte 단위로 수신하는 공격
공격 방법을 자세히 보면 다음과 같다.
RUDY는 FORM을 이용하여서 HTTP Post를 전송하는 웹 페이지에 대해서 Dos공격을 하는 툴이다 .
Content-length를 매우 크게 설정하여서 서버의 지연을 유발하는 공격기법이다.
서버는 클라이언트의 HTTP Header에 Content-length를 보고 그 길이만큼의 Content가 올 때 까지 대기하고 있다.
이점을 이용하여서 초기에 길이를 크게 설정해 놓고 , Content는 일정한 시간 간격으로 한 문자씩 전송한다.
결국 , 서버는 한 세션당 [Content-length * interval Seconds ] 만큼의 지연시간이 발생한다.
그렇다면 WAF에서의 대응방법은 어떻게 될까??
이것또한 마찬가지로 ,
WAF가 가지고 있는 Session timeout 값을 이용하여 세션을 종료한다.
WAF default : 60
MAX Content Length 값 제한
GET Vs POST 차이점
GET 은 주소줄에 값이 ?뒤에 쌍으로 이어붙고 , POST는 숨겨져서 보내진다.
GET은 URL에 이어 붙기 때문에 길이 제한이 있어서 많은 양의 데이터는 보내기 어렵고 , POST는 많은 양을 보내기에도 적합하다
GET은 가져오는 것이고 , POST 는 수행하는 것이다.
GET은 Read 정도 , POST 값 or 상태를 바꿀 때
'학부공부 > 인터넷보안과응용' 카테고리의 다른 글
웹해킹의 이해 (0) | 2018.12.08 |
---|---|
SQL 인젝션이란 무엇인가. (0) | 2018.12.08 |
웹 해킹 침해사고 및 대응 (0) | 2018.12.03 |
WebGoat_sql_injection_Solution(advanced + original ) Webgoat_풀이 (0) | 2018.11.12 |
pip_error (0) | 2018.11.12 |
#IT #먹방 #전자기기 #일상
#개발 #일상