[개발자되기: 인증/보안 2] Day-46

Kyoorim LEE·2022년 7월 15일
ClickjackingJWTOWASPSQL injectionTokenXSScsrfoAuth웹공격토큰
0

코드스테이츠 부트캠프 FE 개념정리

목록 보기
43/54

웹 공격의 종류

SQL Injection (Structured Query Language) 구조적 질의 언어

관계형 데이터베이스 시스템(RDBMS)에서 데이터 관리/처리를 위해 설계된 선언형 프로그래밍 언어

공격 시나리오

  1. 사용자가 input form에 무언가 작성하는 상황에서 발생
SELECT * 
FROM users
WHERE auth='admin'
AND id='kimcoding';
  1. 공격자는 input form에 일반 텍스트가 아닌 SQL문을 작성 
SELECT * 
FROM users
WHERE auth='admin'
AND id='' OR '1'='1'; // '1'='1 은 항상 참이라는 뜻
// WHERE 절에서 OR은 AND보다 연산순위가 낮으므로, OR절인 '1'='1'이 가장 나중에 실행되어 결국 로그인 성공
  1. input form에 SQL문을 마무리하는 키워드인 ;와 함께 주요테이블 삭제문('; DROP TABLES users;--'을 쓰면 데이터가 모두 삭제되는 피해 입을수 O
SELECT * 
FROM users
WHERE auth='admin'
AND id='';DROP TABLES users;--';

대응 방안

  1. 입력(요청)값 검증
    SQL문은 사람이 사용하는 자연어와 비슷하므로 키워드 막기엔 한계가 있음. 화이트리스트 방식으로 해당 키워드가 들어오면 다른 값으로 치환하여 대응
  2. Prepared Statement 구문 사용
    사용자의 입력 값이 전달되기 전에 데이터베이스가 미리 컴파일하여 SQL을 바로 실행하지 않고 대기, 사용자의 입력값을 단순 텍스트로 인식함 => SQL 문이 아닌 단순 텍스트로 적용되어 공격 실패
  3. Error Message 노출 금지
    공격자는 데이터베이스의 에러메세지를 통해 데이터베이스 정보를 얻을 수 있음. 에러가 발생한 SQL문과 에러 내용이 클라이언트에 노출되지 않도록 에러핸들링 필요

Cross-Site Scripting(XSS) 사이트 간 스크립팅

  • 공격자가 웹사이트에 악의적인 스크립트를 심어놓는 행위
  • 주로 클릭유도글 작성 후 해당글 클릭 시 미리 심어놓은 스크립트가 실행되면서 피해 유발
  • 사용자가 의도치 않은 행동 하게 하거나 사용자의 쿠키 등 민감정보 탈취

XSS 공격 유형

1. Stored XSS
스크립트가 서버에 저장되어 여러 사용자에게 피해를 주는 유형
지속적(Persistent) 기법이라고 함
게시판 형태의 웹사이트에서 주로 발생

  • 공격자가 게시판에 텍스트가 아닌 스크립트 담긴 글 작성 => 글은 서버에 저장됨
  • 일반 사용자가 해당글 조회시 HTML로 글의 내용이 화면에 그려지는 과정에서 해당 스크립트가 실행 됨
  • 해당 글은 서버에 저장되어 있으므로 글 조회때마다 스크립트가 실행되어 불특정 다수를 대상으로 공격

2. Reflected XSS
URL 파라미터를 사용헤 스크립트를 만듦
비지속적(Non-persistent) 기법
서버에 저장되지 않으며 웹 어플리케이션의 지정파라미터 사용 시 나타나는 취약점을 이용함
주로 검색엔진에서 공격이 일어남

  • 공격자가 URL 파라미터에 스크립트가 작성된 링크로 사용자 클릭 유도. 주로 피싱(ex. 배송현황 확인 문자)에 사용됨
  • 피해자가 URL 클릭 시 다른 웹사이트 링크로 연결됨 (요청 보내짐)
  • 해당 웹서버는 URL에 담긴 스크립트를 그대로 반사(reflect)하여 클라이언트에 응답을 전송
  • 브라우저가 공격자가 심은 악성 스크립트를 그대로 실행. 쿠키 등 민감정보를 탈취하는 코드 심어놓음

XSS 대응 방안

  1. 스크립트 태그 입력 막기
    • 입력된 값에 태그(<>)와 같은 특수문자 입력되지 않게 하거나 저장요청이 온 글에 태그(<>)와 같은 특수문자 없는 지 검증
    • 글에 포함된 태그(<>)를 HTML 문자참조로 치환 후 저장. <는 &lt; 로 치환하고, >는 &gt;로 치환하고 저장하면 HTML의 태그로 인식되지 않아 스크립트가 실행되지 않음
  2. 쿠키 설정 확인하기(httpOnly)
    쿠키 설정 중 httpOnly 사용 시 스크립트가 쿠키 탈취 하는 경우를 방지해 민감정보 유출을 막을 수 있음
  3. 쿠키에 민감한 정보 담지 않기
    - 민감 정보 서버에서 관리하기
    - 암호화 사용하기

Cross-Site Request Forgery(CSRF)

다른 오리진(cross-site)에서 유저가 보내는 요청을 조작하는 것
(ex. 이메일에 첨부링크를 누르면 내 은행계좌에서 돈이 빠져나감)
단, 다른 오리진이므로 해커가 직접 데이터(response)에 접근할 수 없다

CSRF 공격조건

쿠키를 사용한 로그인인 경우,
예측할 수 있는 요청/parameter를 가지고 있어야 함

  • GET요청으로 CSRF 공격(계좌이체)
  • POST요청으로 CSRF 공격(비밀번호)

CSRF 대응방안

  1. CSRF 토큰 사용하기
    : 서버측에서 CSRF 공격에 보호하기 위한 문자열을 유저의 브라우저와 웹 앱에만 제공
  2. Same-site cookie 사용
    : 같은 도메인에서만 세션/쿠키를 사용할 수 있음

Clickjacking

사용자가 의도한 클릭 대상이 아닌 다른 대상을 클릭하도록 속이는 기법
사용자 인터페이스 덧씌우기(User Interface Redress)라고도 불림
눈에 보이는 화면 위에 눈에 보이지 안흔 다른 행동을 실행하는 화면을 배치

  • 이메일/ 광고문구 등 사용자의 클릭 유도 후 본래 웹페이지와 동일한 피싱사이트로 접근하도록 함
  • 원래 사이트와 동일하게 생겼지만 iframe 태그를 이용해 보이지 않는 버튼 배치
  • 해당 버튼 클릭을 통해 개인정보 탈취 및 사용자의 컴퓨터 제어권 획득

Clickjaking 대응방안

  1. X-Frame-Options
    HTTP의X-Frame-Options헤더 의미
    X-Frame-Options 헤더에 설정한 옵션에 따라 <iframe>의 렌더링 여부를 제한할 수 있음
  2. 콘텐츠 보안 정책 (Content Security Policy, CSP)
    컴퓨터 보안 표준으로 악의적 콘텐츠를 실행하게 하는 보안 공격을 예방하기 위해 도입됨

토큰기반 인증

기존의 세션기반인증은 서버(혹은 DB)에 유저 정보를 담는 방식으로 서버에 부담이 갈 수 있음
이 부담을 클라이언트에게 좀 넘겨주기 위한 목적으로 생겨난 것이 토큰기반 인증

유저정보를 암호화한 상태로 토큰에 담는 것이므로 비교적 안심하고 클라이언트에 저장할 수 있는 것임

JWT (Json Web Token)

Json 포맷으로 사용자에 대한 속성을 저장하는 웹토큰

1. JWT - 액세스 토큰 (Access Token)

보호된 정보들(유저의 이메일, 연락처, 사진)에 접근할 수 있는 권한부여에 사용. 권한부여라는 중요한 역할을 하는 만큼 짧은 유효기간을 줌

2. JWT - 리프레시 토큰 (Refresh Token)

액세스 토큰 유효기간이 만료되면 리프레시 토큰 사용하여 새로운 액세스 토큰 발급받음
유효기간이 긴 리프레시 토큰이 탈취당하면 큰일날 수 있으므로,
유저의 편의보다 정보보안이 더 중요한 웹사이트들의 경우 리프레시 토큰을 사용하지 않는 곳도 많음

토큰기반 인증 절차

  1. 클라이언트가 서버에 아이디/비번을 담아 로그인 요청 보냄
  2. 서버는 아이디/비번 일치하는지 확인 후 클라에게 보낼 암호화된 토큰 생성
    • 액세스/ 리프레시 토큰 모두 생성
  3. 서버가 토큰을 클라에게 보내주면 클라는 토큰을 저장
    • 저장위치는 local storage, session storage, cookie등 다양함
  4. 클라가 HTTP헤더(Authorization 헤더)또는 쿠키에 토큰을 담아 보낸다. 쿠키에는 리프레시 토큰을 헤더, 바디에는 엑세스 토큰을 담는 방법 등 다양하게 구연 가능
  5. 서버는 토큰 해독 후, 발급해준 토큰이 맞다고 판단될 경우 클라의 요청을 처리한 후 응답을 보내줌

토큰기반 인증의 장점

  1. Statelessness & Scalability (무상태성 & 확장성)
  • 서버는 클라에 대한 정보를 저장할 필요 X
  • 토큰을 헤더에 추가하여 인증절차 완료
  1. 안정성
  • 암호화한 토큰 사용
  • 암호화 키를 노출할 필요가 없음
  1. 어디서나 생성 가능
  • 토큰 생성하는 서버가 꼭 토큰을 만들지 않아도 됨
  1. 권한 부여에 용이
  • 토큰의 payload안에 어떤 정보에 접근 가능한지 정의
  • ex. 사진과 연락처 사용권한 부여/ 사진 권한만 부여/ 연락처 권한만 부여

OAuth 2.0

보안된 리소스에 액세스하기 위해 클라에게 권한제공하는 프로세스를 단순화하는 프로토콜 중 한 방법

OAuth에서 알아야 할 용어

  1. Resource Owner: 엑세스 중인 리소스 유저 // 김코딩
  2. Client : 리소스 오너를 대신하여 보호된 리소스에 액세스하는 어플리케이션 // 김코딩이 구글 소셜로그인을 이용해 사용하려는 A라는 애플리케이션
  3. Resource Server: 클라 요청을 수락하고 응답할 수 있는 서버 // 구글 포토
  4. Authorization Server : Resource Server가 액세스 토큰을 발급받는 인증서버
  5. Authorization Grant : 클라가 액세스 토큰을 얻는 방법
  6. Authorization Code: Authorization Grant의 한 타입으로 액세스 토큰을 발급받기 위한 코드
  7. Access Token : 보호된 리소스에 액세스하는 데 사용되는 인증 토큰
  8. Scope: 토큰의 권한

Grant Type

클라가 엑세스 토큰을 얻는 방법
가장 많이 쓰는 Grant Type
1. Authorization Code Grant Type

  • 엑세스 토큰을 받아오기 위해 먼저 Authorization code를 받아 엑세스 토큰과 교환하는 방법
  • 보안성 강화 목적

(위 그림에 단계 추가)
7. App -> App Server: 액세스 토큰과 함께 API요청 보냄
8. App Server -> App: App이 요청한 리소스 전달

  1. Refresh Token Grant Type
  • 일정기간 유효시간이 지나서 만료된 액세스 토큰을 편리하게 다시 받아오기 위해 사용하는 방법

oauth 스프린트 과제 관련 flow

  1. 환경변수 세팅부터 .env.example => .env로 바꾸고 아이디랑 시크릿 넘버 넣기
    (서버랑 클라이언트 다)
    REACP_APP_CLIENT_ID=
profile
Kyoorim LEE
oneThing
이전 포스트

[개발자되기: Auth Basic 아윤님 강의 노트]

다음 포스트

[개발자되기: 기술면접] Day-47

0개의 댓글