웹 보안 공격

1. SQL Injection

 1) 공격 방식

• 데이터베이스에서 임의의 SQL문을 실행할 수 있도록 명령어를 삽입하는 공격 유형이다
• 응용 프로그램의 보안상의 허점을 이용해 데이터베이스를 비정상적으로 조작하여 기록을 삭제하거나 데이터를 유출한다

 

2) SQL Injection 대응

• 입력(요청) 값을 검증한다
  - SQL문은 사람이 사용하는 자연어와 비슷하기 때문에 키워드를 막기에는 한계가 있다
  - 블랙리스트가 아닌 화이트리스트 방식으로 해당 키워드가 들어오면 다른 값으로 치환하여 SQL Injection에 대응할 수 있다
    : 화이트리스트란 기본 정책이 모두 차단인 상황에서 예외적으로 접근이 가능한 대상을 지정하는 방식 또는 그 지정된 대상들을 말한다

• Prepared Statement 구문을 사용한다
  - Prepared Statement 구문을 사용하면 사용자의 입력이 SQL문으로부터 분리되어 SQL Injection을 방어할 수 있다
  - 사용자의 입력 값이 전달 되기 전에 데이터베이스가 미리 컴파일하여 SQL을 바로 실행하지 않고 대기한다
  - 사용자의 입력 값을 단순 텍스트로 인식하여 입력 값이 SQL문이 아닌 단순 텍스트로 적용되어 공격에 실패한다
• Error Message 노출을 금지한다
  - 공격자는 데이터베이스의 Error Message를 통해 테이블이나 컬럼 등 데이터베이스의 정보를 얻을 수 있다
  - 에러가 발생한 SQL문과 에러 내용이 클라이언트에 노출되지 않도록 별도의 에러핸들링이 필요하다

 

2. Cross-Site Request Forgery (CSRF)

• 다른 오리진(cross-site)에서 유저가 보내는 요청을 조작(forgery)하는 것이다
• 다른 오리진이기 때문에 공격자가 직접 데이터를 접근할 수 없다

 1) 공격 조건

• 클라이언트가 로그인 했을 경우에 쿠키로 클라이언트를 확인할 수 있어야 한다
• 클라이언트가 요청한 parameter에 예측할 수 있는 정보가 담겨있어야 한다
• GET 요청으로 CSRF 공격
  - http://bank.com/transfer?account_number=username&amount=1000$
  → http://bank.com/transfer?account_number=user계좌번호&amount=1000$
  → http://bank.com/transfer?account_number=해커계좌번호&amount=1000$

 

• POST 요청으로 CSRF 공격
  - POST : http://bank.com/password/change
  - BODY : {password:user's-new-password}

 

 2) Cross-Site Request Forgery 대응

• CSRF 토큰을 사용한다
  - 서버측에서 CSRF 공격에 보호하기 위한 문자열을 클라이언트의 브라우저와 웹 앱에만 제공한다 
• SAME-site coolie를 사용하여 같은 도메인에서만 세션과 쿠키를 사용할 수 있도록 한다

 

 

※ 참조 링크

▶ "동일 사이트" 및 "동일 출처" 이해하기 : https://web.dev/same-site-same-origin/#same-site-cross-site

"동일 사이트" 및 "동일 출처" 이해하기