XSS 와 CSRF

XSS(Cross Site Scripting)

---

Web Application에서 나타나는 취약점중 하나로 웹사이트 관리자가 아닌 이가 사이트에 악성 script를 삽입할 수 있는 취약점이다. 사용자의 쿠키, 세션 탈취, 비정상기능 수행등을 한다.

• html이 <script> </script> 를 자바스크립트라고 인식해서 실행한다.
• 악성코드를 퍼트릴 때 많이 사용한다.

 

다음과 같은 경우에 발생

1. 데이터는 신뢰할 수 없는 소스를 통해 웹 응용 프로그램에 입력되며 가장 자주 웹 요청이 발생합니다.
2. 데이터는 악성 콘텐츠의 유효성을 검사하지 않고 웹 사용자에게 전송되는 동적 콘텐츠에 포함됩니다

 

 

1. Reflected XSS - non persistent

• 요청과 동시에 결과가 사용자에게 반사되는 형태
• 클라이언트 요청에서 전송된 악성 스크립트는 서버에 전송되고, 브라우저에서 실행되는 HTML 코드에 다시 표시, 쿼리 매개변수에 스크립트를 포함한다.
• 반사형 XSS 공격은 피해자가 직접 스크립트를 실행하도록 유도하기 때문에 1회성 공격이라고도 함

 

 

2. Stored XSS - persistent

• 공격자가 제공한 데이터가 서버에 저장된 후 지속적으로 서비스를 제공하는 정상 페이지에서 다른 사용자에게 스크립트가 노출되는 기법
• 사용자의 브라우저에서 서버에 데이터를 요청할 때마다 실행되어 지속적으로 피해 발생
• Stored XSS가 위험한 이유는 사용자가 링크를 클릭하도록 유인할 필요가 없다는 것
• 더 많은 희생자를 목표로 삼지만 더 적은 리소스가 필요

 

다양한 공격 기법

1. a herf : 링크를 이용
2. img src : 이미지 태그를 이용
3. IFRAME 안에 스크립트를 담는 방법을 이용
4. 아스키 코드를 이용

 

 

3. Dom XSS

웹페이지를 여는 즉시 생성되는 문서 객체 모델(Document Object Model, DOM)은 사용자가 서버와 상호 작용하지 않고도 페이지의 모든 콘텐츠에 액세스할 수 있도록 돕는 프로그래밍 인터페이스

• 피해자의 브라우저에 초점을 맞춘 것이 특징인 공격
• DOM 기반 XSS는 웹사이트의 코드를 조사하지 않고는 취약점을 발견할 수 없다.

 

 

XSS 위험한 이유

사용자의 세션 정보와 같은 민감한 데이터를 훔쳐 해커가 해당 사용자를 가장할 수 있다.

• 관리자일 경우 웹 사이트 제어 가능

삽입된 스크립트를 사용하여 웹 사이트의 콘텐츠 변경이나, 브라우저를 다른 웹 페이지로 리디렉션 가능

 

 

방지하려면?

 

User input value 제한

• ⭐사용자의 입력은 믿을 수 없다.
• 유저 입력값이 한정적인 범주안에서 예측 가능하다면, 드롭다운 등을 사용하여 미리 입력될 데이터값을 통제할 수 있다.

출력할 때 스크립트 제한

• ⭐사용자가 입력한 값을 그대로 출력하지 않는다.
• HTML ESCAPE

Sanitize value - DB에 저장할 때

• 악성 HTML을 필터링해주는 라이브러리 사용도 가능하다.
• ex) lucy xss filter - naver

스크립트 문자 필터링

• DOM 상의 텍스트를 읽을 때 html 태그를 읽는 innerHTML 사용을 지양하고, textContent 등으로 메소드를 대체한다.

쿠키 HttpOnly

• 자바스크립트에서 접근 불가(documet.cookie)
• HTTP 전송에만 사용

 

 

 

 

CSRF(Cross Site Request Forgery)

---

공격자가 작성해 놓은 악성스크립트 [사이트에서 제공하는 기능을 피해자의 웹 브라우저에서 요청] 을 통해서 일어나는 악의 적인 공격 방식. 피해자는 공격자가 게시한 글을 읽었을 때 악성스크립트에 의한 요청이 서버로 보내지게 되고 서버는 피해자의 권한 내에서 해당 악성 스크립트 요청을 처리하게 된다.

즉, ⭐사용자의 의지와는 무관하게 공격자가 의도한 행위를 특정 웹사이트에 요청하게 하는 공격

• XSS와 달리 자바스크립트를 사용할 수 없는 상황에서도 공격이 가능

 

공격을 위한 몇가지 조건 필요

1. 사용자가 보안이 취약한 서버로부터 이미 인증을 받은 상태여야 합니다.
2. 쿠키 기반으로 서버 세션 정보를 획득할 수 있어야 합니다.
3. 공격자는 서버를 공격하기 위한 요청 방법에 대해 미리 파악하고 있어야 합니다. 예상치 못한 파라미터가 있으면 불가능합니다.

 

방지하려면?

• csrf는 다른 사이트에서 요청을 보내는 공격이기 때문에 다른 사이트에서 오는 요청을 막거나, 올바른 사이트에서 보내는지 확인하는 수단이 필요
• "Referer"등의 Header를 이용하여 경로를 검사
• 요청 도메인과 쿠키에 설정된 도메인이 같은 경우에만 쿠키 전송 → 쿠키 값이 다른 곳으로 넘어가지 안게 한다.
• 단순한 세션 토큰만을 이용한 권한 부여 금지
• ⭐GET은 read 데이터의 변화가 없다, POST는 사용자의 명시적인 액션이 있어야 한다
• 즉 GET 으로 데이터의 변화가 일어나게 설계를 하면 안된다.
• CSRF 토큰 사용

 

 

 

결론

• !!시큐어 코딩을 잘 하자  -> 행정안전부 시큐어코딩 가이드라는게 존재
• 개발에 있어 그 누구도 믿지마라.
• 철저하게 권한과 책임을 분리하자.

 

 

 

 

 

[참고]

https://www.youtube.com/watch?v=TDgy1LzOnIk&ab_channel=%EB%84%90%EB%84%90%ED%95%9C%EA%B0%9C%EB%B0%9C%EC%9E%90TV 

https://portswigger.net/web-security/cross-site-scripting