[데브코스] TIL-131 React, 웹 보안 공격, SPA 역사

 웹 보안

 

  웹 사이트의 취약점을 공격하는 기술적 위협으로, 웹 페이지를 통해 권한이 없는 시스템에 접근하거나 데이터 유출 및 파괴와 같은 행위를 말한다.

 

웹 보안 공격 기법

1. SQL Injection

  서버에서 실행되는 SQL을 악의적으로 이용하는 공격이다. 기존 SQL에 악의적인 SQL을 삽입한다. 그렇기 때문에 데이터 탈취나 삭제 등이 가능하다.

 

방어 방법

• SQL에서 특별한 의미를 가지는 문자를 이스케이프한다.
  • \\n, \\t, |, /, &, # …
• 준비된 선언을 사용한다.
  • placeholder를 담은 SQL을 먼저 DB에 보낸 후 placeholder에 해당하는 입력 값을 DB에 보내는 방식
• 라이브러리, 프레임워크에서 거의 100% 막아준다.

심화 공격

1. Error based SQL ****************Injection
2. 일부러 SQL 에러를 발생시켜 원하는 정보를 취득한다. 쿼리문 추측, DB명, 테이블명 등을 취득할 수 있다.
3. Blind SQL Injection
4. 쿼리 결과의 참/거짓을 보고 원하는 정보가 존재하는지 알 수 있다. DB명, Table명을 알 수 있다. SQLMap이라는 자동화된 툴을 이용하기도 한다.
5. Union SQL Injection
6. Union 명령을 이용하여 정보를 취득한다.

2. XSS

  Cross-Site Scripting이며, 웹 페이지에 악성 스크립트를 삽입하는 공격이다. 사이트 이용자의 정보를 탈취할 수 있기 때문에 주의해야 한다.

 

방어 방법

• HTML 필터링을 한 후 DB에 저장한다.
  • <, >, script, html, head, meta
• 만약을 위해 프론트엔드에서도 태그와 관련된 것들을 필터링한다.

심화 공격

1. Reflected XSS
2. 검색어 등을 보여주는 곳에 스크립트를 심는 공격이다. URL을 사용자에게 누르게 만들면 공격이 성공하게 된다.
3. DOM Based XSS
4. DOM에 악의적인 스크립트를 심는 공격이다. 이는 브라우저가 스크립트를 해석하는 단계에서 발생된다.

3. CSRF Attack

  Cross-Site Request Forgery이며, 공격자가 사용자를 이용하여 웹 사이트에 요청을 보내는 공격이다.

 

방어 방법

• Referrer Check
  • 허용한 도메인만 요청을 허락하도록 설정한다.
• CSRF Token
  • 모든 요청에 토큰을 발급하여 서버에서 검증한다.
• CAPTCHA
  • 사람이 요청한 것이 맞는지 검증한다.

4. Command Injection

  애플리케이션에 사용 되는 시스템 명령에 악의적인 명령어를 삽입하는 공격이다. 이는 웹을 통해서 해당 시스템의 Shell에 접근할 수 있기 때문에 WebShell Attack이라고도 부른다. 서버의 root 권한을 취득할 수 있다.

 

방어 방법

• 가급적 시스템 함수를 사용하지 않는다.
• 민감한 문자를 필터링한다.
  • |, &, ;, >, <

5. File Upload Attack

  악성 스크립트 파일을 업로드하는 공격이다. 업로드 후 파일 위치를 찾아 실행시키면 공격이 성공하게 된다. 보통 php, jsp를 사용하는 곳에서 공격 받을 수 있다.

 

방어 방법

• 확장자나 파일 타입을 검사한다.
• 업로드 파일을 난수화하여 저장한다.
• 특수 문자가 포함된 경우 업로드를 금지시킨다.

6. JavaScript Injection

  Client-Side에서 JavaScript를 삽입시키는 공격이다. 크롬 콘솔 등을 통해 조작이 가능하며, Client-Side에 민감한 데이터를 넣을 경우 탈취가 가능하다.

 

방어 방법

• Client-Side에는 민감한 정보를 절대 넣지 않는다.
• 데이터 유효성 검사가 필요한 경우에는 서버와 통신한다.
  • 중요한 데이터를 Client에서만 검사하면 안된다.

7. DDoS

  Distributed Denial of Service이며, 서버에 비정상적으로 많은 트래픽을 보내는 공격이다. 서비스가 마비되고 많은 비용이 소모된다.

 

방어 방법

• 제일 단순한 방법인데 제일 막기 어렵다.
• 확장 가능한 서비스 구조를 설계한다.
• IP 필터링을 하거나 Rate Limit을 걸어 둔다.
  • ex) 3초에 10개만 요청을 받겠다.
• DDoS를 탐지해서 바로 차단시켜주는 솔루션을 구매한다.

8. Dictionary Attack

  미리 사전에 등록해놓은 문자열을 암호로 대입하는 공격이다. Brute Force의 일종이라고 볼 수 있다.

 

방어 방법

• 의미가 있는 문자열은 암호로 등록하지 못하도록 설정한다.
• 특정 횟수이상 비밀번호를 틀렸을 때 계정을 잠그는 Account Lockout Policy를 적용한다.
• OTP 같은 2-factor 인증을 사용한다.

9. Rainbow Table

  해시 함수를 이용한 평문을 모두 저장시켜 놓은 표를 의미한다. 이는 이미 해킹이 되었을 때를 가정하는데, 계정 탈취 후 암호 원문을 알아내기 위해 사용한다.

 

방어 방법

• Salt
• Key Stretching
• PBKDF2, Bcrypt 등의 암호화 알고리즘을 사용한다.

 

보안 정책

1. CORS

  Cross-Origin Resource Sharing이며, 개발자가 지정한 프로토콜, 도메인, 포트가 아니라면 리소스를 가져올 수 없게 하는 것이다. 브라우저가 Response header를 보고 허용 여부를 결정하기 때문에 브라우저마다 구현이 다를 수 있다.

2. CSP

  Content-Security-Pocliy이며, 실행 가능한 리소스에 대한 Whitelist를 정하는 정책이다. 웹 사이트가 허용되지 않은 리스소를 요청하지 못하도록 막는다. 따라서 XSS 방지에 도움이 된다. 기본적으로는 inline script가 실행을 막는다. 메타 태그나 HTTP header로 설정이 가능하다.

<meta http-equiv="Content-Security-Pocliy"
    content="default-src 'self'; connect-src 'self'; script-src 'none';
    style-src 'self'; img-src https://cdn.cobalt.run" />

3. HTTPS

  HTTP 프로토콜의 암호화된 버전이다. SSL 인증서를 이용하여 소켓 통신에 암호화된 데이터를 전송한다.

SPA의 역사

  태초에 Muti Page Application(MPA)이 있었다. 이는 먼저 사용자가 브라우저를 통해 특정 페이지를 요청하고, 서버는 요청을 받아 데이터를 그에 끼워넣은 후 HTML String을 만들어 낸다. 이를 사용하여 HTML을 반환하면 브라우저가 렌더링하는 방식이다.

이 때는 자바스크립트의 역할이 크지 않았다. 그러나 점점 화려한 애니메이션, 멀티미디어 재생, 동적인 데이터 전송 등 브라우저에 요구사항이 많아졌다.

1. Ajax

  그래서 이를 해결하기 위해 Ajax가 등장했다. 구글이 적극적으로 사용하면서 유행하기 시작한 기술이며, 페이지 이동이 없이 통신이 가능했다. 즉, 동적으로 데이터를 가져올 수 있었다. 그렇다면 페이지 이동 없이 페이지를 가져올 수는 없을까라는 의문이 등장했다.

2. Hashbang

  이 때 URI Fragment를 이용한 Hashbang이라는 개념이 등장했다. URI Fragment는 URI에 #이 붙은 부분을 뜻한다. URI Fragment를 읽은 후 해당 경로에 해당하는 페이지를 Ajax로 불러오는 방식이다. 그래서 화면 깜빡임 없이 전환이 가능하고 사용자에게 로딩도 보여줄 수 있어 사용성이 향상되나, 검색 엔진 최적화의 문제가 있었다.

3. History API

  이 문제는 HTML5 History API가 등장하며 사라진다. pushState(), replaceState()와 같은 기능이 생기면서 페이지 이동 없이 브라우저의 주소를 변경할 수 있게 되었다.

4. pjax

  pushState를 적극적으로 사용하면서 pushState와 Ajax를 합친 pjax라는 용어도 등장했다. 이는 Hashbang의 단점을 모두 보완한다. pjax로 MPA와 1:1 대응이 가능해졌다. 첫 페이지 접속은 서버에서 내려주는 HTML을 렌더링하고, 이후에는 ajax로 HTML을 불러와 교체하는 방식이다. 어떻게 보면 이것은 SSR의 시작이라고 볼 수 있다.

 

오늘을 마무리 하며

 

  오늘은 뭔가 신기한 내용들에 대해서 공부를 많이 한 것 같다. 이전에 뉴스에서만 보았던 DDos 공격이 어떤 공격인지에 대해서도 알 수 있었고 생각보다 많은 부분에서 공격을 받을 수 있다는 점도 알 수 있었다. 그리고 웹 개발을 할 때 대부분의 웹 페이지는 개인 정보를 수집하게 되는데 이런 개인 정보와 관련된 데이터를 보호하기 위해서도 신경을 써야 한다는 점을 알 수 있었다. 역시 개발의 세계는 정말 넓다는 느낀 강의가 아니었나 생각이 든다.