[DAY-56] 오픈 API 활용 웹사이트 제작

블로그 썸네일-028

😉 헷갈렸던 & 몰랐던 부분들만 정리하는 나만의 TIL
😯 모든 강의 내용은 적지 않아요!

오늘의 소감은?
내일 강남 가서 또 정염소 나올 것 같다.
떨려 죽겠네..
오늘 마저 복습하고 자야겠다.

프로젝트 시작 전 각오 : 몰라도 부딪히며 이겨내 보자.

1. 웹 보안 공격

웹 보안이란, 웹 사이트의 취약점을 공격하는 기술적 위협으로

웹 페이지를 통하여 권한이 없는 시스템에 접근하거나 데이터 유출 및 파괴와 같은 행위를 말한다.

이는 정말 다양한 기법이 존재한다.

SQL Injection
XSS
CSRF Attack
File Upload Attack
Command Injection
Buffer Overflow
Dictionary Attack

이 외에도 정말 다양한 공격 기법이 존재한다.

따라서 우리는 서비스를 한 순간에 망치지 않기 위해 기초적은 대응법은 꼭 알아두는 것이 좋다.

1.1 SQL Injection

SQL Injection은 서버에서 실행되는 SQL을 악의적으로 이용하는 공격 기법이다.

기존 SQL에 악의적인 SQL을 삽입하여 데이터 탈취, 삭제 등이 가능하다.

이를 방어할 수 있는 방법이 몇가지 있다.

SQL에서 특별한 의미를 가지는 문자를 이스케이프한다. (ex. \n, \t, |, /, &, #, …)
준비된 선언을 사용한다. (Placeholder을 담은 SQL을 먼저 DB에 보낸 후, Placeholder에 해당하는 입력 값을 DB에 보낸다.)
다양한 라이브러리, 프래임워크를 사용한다.

Error based SQL Injection

일부러 SQL 에러를 발생시켜 원하는 정보를 취득하는 SQL Injection 심화 공격 방법이다.

쿼리문 추측, DB명, 테이블명 등을 취득할 수 있다.

Query 결과의 참/거짓을 보고 원하는 정보가 존재하는지 알 수 있다.

DB, 테이블명을 취득할 수 있으며, SQLMap이라는 자동화된 툴을 이용하기도 한다.

Union SQL Injection

Union 명령을 이용하여 정보를 취득하는 기법이다.

1.2 XSS

Cross-Site-Scripting의 줄임말이다.

이는 웹 페이지에 악성 스크립트를 삽입하는 공격 방식이며, 웹 사이트 사용자의 정보를 탈취할 수 있다.

이는 HTML 필터링 후 DB에 저장하는 방식을 사용하여 방어할 수 있다.

또한 프론트 측에서도 입력 부분에 특정 로직을 적용함으로써 이를 방어할 수 있다.

Stored XSS

가장 일반적인 XSS 기법이다.

input 창 등에 스크립트를 심는 공격이다.

Reflected XSS

검색어 등을 보여주는 곳에 스크립트를 심는 공격이다.

URL을 사용자에게 누르게 만들면 공격에 성공한다.

DOM Based XSS

DOM에 악의적인 스크립트를 심는 공격이다.

브라우저가 해당 스크립트를 해석하는 단계에서 발생되는 공격이다.

요즘 브라우저는 해당 공격 방법을 기본적으로 막아주지만, 옛 버전의 브라우저를 사용하는 사용자들은 충분히 공격당할 가능성이 존재한다.

1.3 CSRF Attack

CSRF란 Cross-Site Request Forgery의 줄임말이다.

공격자가 사용자를 이용하여 웹 사이트에 요청을 보내는 공격 방식이다.

예를 들어 가짜 피싱 사이트를 이용한 공격 방식이 바로 CSRF이다.

이를 방어할 수 있는 몇가지 방식이 있다.

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

1.4 Command Injection

어플리케이션에서 사용되는 시스템 명령에 악의적인 명령어를 삽입하는 공격이다. (Webshell Attack)

서버 root 권한을 취득할 수 있는 아주 강력한 공격이지만, 요즘 시대에서는 발견하기 힘든 공격 방식이다.

이를 방어하기 위해서 가급적 시스템 함수를 사용하지 않는 것이 좋다.

만약 정말 사용해야 한다면 민감한 문자( &, ;, >, < 등)를 필터링해서 사용하는 것이 좋다.

1.5 File Upload Attack

악성 스크립트 파일을 업로드하는 공격이다.

업로드 후 해당 파일의 위치를 찾아 실행시키면 공격에 성공한다.

현재는 PHP나 JSP를 거의 사용하지 않기 때문에, 해당 공격 방법을 발견하기 힘들다.

이를 방어할 수 있는 방법이 몇가지 있다.

확장자 / 파일 타입 검사
업로드 파일 난수화하여 저장
특수 문자가 포함된 경우 업로드 금지

1.6 JavaScript Injection

Client-side에서 JS를 삽입시키는 공격이다.

크롬 console 등을 이용하여 조작 가능하다.

따라서 Client Side에 민감한 데이터를 넣은 경우 쉽게 탈취당할 수 있다.

이를 방어하기 위해서는 Client Side에는 민감한 정보를 절대 넣지 말아야 한다.

또한 데이터 유효성 검사가 필요한 경우, 서버와 통신해야 한다.

(중요한 데이터는 Client 측에서만 검사하면 안된다. )

1.7 DDoS

Distributed Denial of Service의 줄임말로, 서버에 비정상적으로 많은 트래픽을 보내는 공격이다.

따라서 서비스가 마비되거나 엄청난 비용이 발생할 수 있는 공격 방식이다.

공격자는 단순하게 Zombie PC를 사용하여 수많은 트래픽을 보내기만 하면 되는 정말 단순한 방법의 공격이다.

가장 단순한 방법의 공격이지만, 가장 막기 어렵다.

확장 가능한 서비스 구조를 설계한다.
IP 필터링을 통해 비정상적으로 많은 트래픽이 몰리는 IP를 차단한다.
Rate Limit을 설정한다.
솔루션을 구매한다.

1.8 Dictionary Attack

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

요즘에는 다양한 비밀번호 조건이 늘어나면서 해당 공격은 발견하기 힘들다.

이를 방어하기 위해서 몇가지 방법을 사용할 수 있다.

의미가 있는 문자열 (banana, …) 등은 암호로 등록하지 못하도록 설정한다.
Account Lockout Policy로 특정 횟수 만큼 로그인이 실패한다면 해당 계정을 차단한다.
2-factor 인증을 도입한다.

1.9 Rainbow Table

Rainbow Table은 해킹을 당했다는 가정 하에 사용할 수 있는 공격 방법이다.

해당 표는 해시 함수를 이용한 평문을 모두 저장시켜 놓은 표이며,

계정 탈취 후 암호 원문을 알아내기 위해 사용한다.

이를 방어하기 위해 몇가지 방법을 사용할 수 있다.

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

[2] 보안 정책

알아야 하는 보안 정책에 대해 몇가지 정리한다.

2.1 CORS

Cross-Origin Resource Sharing의 줄임말이다.

개발자가 지정한 프로토콜, 도메인, 포트가 아니라면 리소스를 가져올 수 없게 하는 보안 정책이다.

브라우저가 Response Header를 보고 허용 여부를 정하게 되며, 해당 구현은 브라우저마다 다르다.

2.2 CSP

Content-Security-Policy의 줄임말이다.

실행 가능한 리소스에 대한 Whitelist를 정하는 정책이다.

따라서 웹 사이트가 허용되지 않은 리소스를 요청하지 못하도록 막으며, XSS 방지에 도움이 된다.

(기본적으로 inline script는 실행을 막기 때문이다.)

메타 태그, 혹은 HTTP Header로 설정 가능하다.

2.3 HTTPS

HTTP 프로토콜의 암호화된 버전이다.

소캣 통신에 암호화된 데이터를 전송하며, SSL 인증서를 이용한다.

[3] SPA 역사

Single Page Application인 SPA가 어떻게 등장했고, 언제 유행하기 시작했는지 역사를 짚어본다.

먼저 태초에 MPA(Multi Page Application)이 존재했다.

이 당시에는 너무나도 당연하게 MPA 방식을 사용했고, 웹 상에서 JavaScript의 역할이 크지 않았다.

하지만 점점 브라우저에 애니메이션 등의 요구사항이 많아지기 시작했다.

이는 모바일 환경의 사용성이 증가하면서 더욱 많아지게 되었다.

1999

따라서 1999년에 해당 문제를 해결하기 위한 Ajax(Asynchronous JavaScript and XML)가 등장했다.

2004

예를 들어 페이지 이동 없이 지도를 확인할 수 있는 Google Map이 Ajax를 이용한 대표적인 사례였다.

2010

페이지 이동을 하지 않고도 페이지 전환의 효과를 줄 수 있지 않을까의 발상에서 시작되어

Hashbang(URI Fragment) + Ajax의 사례가 등장했다.

하지만 Hashbang은 검색 엔진에 잡히지 않는다는 치명적인 문제가 있었다.

2012

이 문제는 생각보다 빠르게 해결되었다.

바로 HTML5 History API의 pushState(), replaceState()와 같은 기능을 이용하여 페이지 이동 없이 브라우저의 주소를 변경할 수 있게 되었기 때문이다.

2015

해당 History API(PushState)와 Ajax를 함께 사용하며 더욱 좋은 효과를 낼 수 있었다. (Pjax)

Pjax의 등장으로 MPA와 1:1 대응이 가능해졌다.

이는 첫 페이지 접속은 서버에서 내려주는 HTML을 렌더링, 이후에는 ajax로 HTML을 불러와서 교체할 수 있다는 의미이다.

2018

MPA의 1:1에서 시작된 SSR(Server side rendering) 구현이 쉬워지며 유행이 커지게 되었다.,

또한 JQuery가 물러나고, React, Vue, Angular의 SPA 구현을 쉽게 해주는 다양한 오픈소스가 등장했다.

이로 인해 SPA는 더욱 유행하게 되었다.

[4] 프로젝트 시작 전..

프로젝트 시작이 바로 다음날로 다가왔다.

이선협 강사님의 팀 빌딩 및 프로젝트 가이드를 듣고 몇 가지를 짧게 간추려보았다.

커뮤니케이션

의견이 충돌되는 것은 나쁜 신호가 아니다. 오히려 좋은 신호라고 받아들일 수 있다.

왜냐, 프로젝트를 위해 의견을 낸 것이기 때문이다.

이와 같은 상황이 많다면, 오히려 다양한 의견을 많이 접할 수 있다.

하지만 의견이 잘 좁혀지지 않는다면, 먼저 한 가지를 고른 뒤 구현, 테스트, 피드백의 절차를 거치는 것이 좋다.

당연하게도 커뮤니케이션의 과정에서 기본적인 예의는 지켜야 한다.

업무 프로세스

Waterfall Model, Prototype Model, Spiral Model, Agile Model의 여러 방법론이 있다.

이 방법론 중 하나를 택하는 것이 아닌, 참고하여 우리 팀만의 프로세스를 구축하는 것이 중요하다.

스프린트나 테스크 정리는 기능 요구사항, 비기능 요구사항을 나누어 작성한다.

기능 요구사항 : 사용자에게 제공되는 기능
비기능 요구사항 : 서비스가 되어야 하는 품질

Kanban 보드를 사용하여 업무의 상황을 빠르게 파악하는 것도 좋다.

사용자 스토리

사용자 스토리는 시스템이 제공하는 기능을 사용자 관점에서 기술한 것이다.

중요한 가치는 꼭 사용자 스토리를 통해 나오는 것이 좋다.

사용자 스토리를 위한 태스크는 적당한 크기로 나눠야 한다.

짧으면 1-2시간, 길면 3-4시간 안에 끝낼 수 있는 일의 단위로 나누는 것이 좋다.

규칙 정하기

당장 정할수 있는 여러 규칙이 있다.

기술 스택
커밋 메세지
코드 리뷰
브랜치 전략
컴포넌트 레이어
업무 프로세스, 방법론 등

여기서 중요한 것은, 규칙 정하기에 가장 중요한 것은 일이 잘 되게끔 하는 것이다.

오히려 일의 차질을 만들어내는 규칙은 수정하거나 삭제하는 것이 맞다.

기본적인 규칙을 먼저 정하고 그 외의 규칙은 일을 진행하다 필요할 때 세우는 것이 좋다.

출처

프로그래머스

Twitter Facebook LinkedIn