# 인바운드 & 아웃바운드

 

방화벽이란

서버와 서버 간 통신을 하는데 있어서

정의된 보안 규칙에 기반하여

네트워크 트래픽을 제어하는 보안 시스템이다.

쉽게 말하자면

어떤 곳에서 파티가 열렸는데

그 파티에 참석하려면 파티 인원으로 등록된 인원만 출입이 가능하다

파티장 앞에서 등록된 사람만 들여보내주는 역할을 하는게

바로 방화벽의 역할이다.

 

서버간 통신을 하다보면

데이터가 서버로 들어오는 경우가 있고

데이터가 서버밖으로 나가는 경우가 있다.

이때, 데이터가 서버로 들어오는 경우를 인바운드라 하고

데이터가 서버 밖으로 나가는 경우를 아웃바운드라 생각하면 된다.

 

예를 들자면

첨부파일을 서버에 저장한다 = 인바운드

첨부파일을 다운로드 한다 = 아웃바운드

한가지 더 알아야 할 것이 있는데 데이터 전송 방식이다.

데이터 전송 방식은 TCP와 UDP가 있는데

TCP는 신뢰성을 우선시하고

UDP는 성능을 우선시한다.

 

1,2,3이라는 데이터를 보낸다고 생각하자.

TCP 프로토콜은 데이터를 받는 입장에서 1,2,3 순서대로 데이터를 받겠지만

UDP 프로토콜은 1,2,3으로 오든 2,3,1로 오든 데이터를 받기만 하면 된다.

그리고

TCP는 받는 쪽에서 데이터를 잘 받았는지 확인하는 절차가 있는 반면

UDP는 데이터 보내기만 하면 끝이다.

 

그럼 방화벽을 여는 법을 알아보자

<리눅스>

### 인바운드 오픈
# 192.168.123.60 서버가 5432 포트로 들어오도록 허용
iptables -I INPUT 1 -s 192.168.123.60 -p tcp --dport 5432 -j ACCEPT
# 192.168.123.60 서버에 대한 인바운드 모든 포트를 허용
iptables -I INPUT 1 -s 192.168.123.60 -p all -j ACCEPT

### 아웃바운드 오픈
# 192.168.123.60 서버가 5432 포트로 나가도록 허용
iptables -I OUTPUT 1 -s 192.168.123.60 -p tcp --dport 5432 -j ACCEPT
# 192.168.123.60 서버에 대한 아웃바운드 모든 포트를 허용
iptables -I OUTPUT 1 -s 192.168.123.60 -p all -j ACCEPT

# 주의! 테스트 안함 ㅋ 참고용

 

<윈도우>

제어판 > Windows Defender 방화벽 > 고급 설정

> 인바운드/아웃바운드 규칙 > 새규칙 > 

포트 선택 + 다음 > TCP(기본) + 모든/특정 로컬 포트(특정 port 입력) + 다음

> 연결 허용 + 다음 > 다음 > 이름 및 설명 입력 마침

 

[참고자료]
https://prinha.tistory.com/entry/%EB%B0%A9%ED%99%94%EB%B2%BD
https://mangkyu.tistory.com/15
https://yunyoung1819.tistory.com/20

 

 

To be continued.........

 

 

Made by 꿩

'IT > 보안' 카테고리의 다른 글

[Spring] Google reCAPTCHA v3  (6) 2019.07.07
OAuth  (0) 2019.06.17
SSL인증서  (0) 2019.03.21
CSRF  (0) 2018.12.25
XSS 공격과 방어  (2) 2018.10.25

#[Spring] Google reCAPTCHA v3

 

 

오늘은 자동화 공격에 대한

구글이 제공하는 reCAPTCHA에 대해 소개하려 한다.

reCAPTCHA는 자동화 공격을 막기 위한 방법으로

흔히들 아는 "로봇이 아닙니다"를 떠올이면 된다.

자동화 공격은 사람이 아닌 기계로 공격을 하는 것으로

매크로를 만들어 불법적인 프로그램을 사용하거나

로그인을 할 때 비밀번호를 기계가 자동으로 입력하여

계정을 해킹하는 것 등을 말한다.

Google reCAPTCHA v2는

의심스러운 트래픽이 발생하면

'로봇이 아닙니다'를 증명하기 위해

사람만이 판단할 수 있는 이미지를 클릭하는 방식으로 방어하는 방식이다.

하지만 v2 방식은 이용자들에게 불편함을 주는 방식으로

이미지를 클릭해도 다른 이미지가 나와 여러번 클릭하거나

로그인할 때마다 로봇이 아니라는 것을 인증해야 해서

빡친 사람은 나뿐만이 아닐 것이다.

속사정은 모르지만

아마도 사용자를 방해한다는 피드백이 있어

reCAPTCHA v3가 나온 것이 아닐까 추측한다.

reCAPTCHA v3는 v2와 다르게 사용자를 방해하지 않는다.

사용자의 행동(action)을 보고 기계인지 사람인지 판단하는 방법이다.

reCAPTCHA v3는 0 ~ 1.0 까지의 점수를 서버에 보내주는데

0에 가까울수록 기계에 가깝다는 뜻이고

1에 가까울수록 사람에 가깝다고 알려준다.

간단하게 reCAPTCHA v3를 한번 구현해보자.

먼저, Google reCAPTCHA 사이트에 들어가 admin console 사이트를 등록한다.

https://www.google.com/recaptcha/intro/v3.html

 

v3 유형을 선택하고

도메인은 test용이니 localhost를 등록한다.

완료가 되면 사이트 키와 비밀 키를 받는데

설정에서 그 내용을 확인할 수 있다.

그 다음

Spring으로 간단한 maven 프로젝트를 생성한다.

recaptcha.jsp 파일은 다음과 같이 작성하였다.

<%@ page language="java" contentType="text/html; charset=utf-8" pageEncoding="utf-8"%>
<html>

<head>
    <meta charset="UTF-8">
    <title>구글 리캡챠 테스트</title>
    <script src="https://code.jquery.com/jquery-3.4.1.min.js" integrity="sha256-CSXorXvZcTkaix6Yvo6HppcZGetbYMGWSFlBw8HfCJo=" crossorigin="anonymous"></script>
    <script src="https://www.google.com/recaptcha/api.js?render=6Le-q6kUAAAAAFPDTU6lct7ZRRN7vK55hVF4Icp3"></script>
</head>

<body>
    <form action="/robot" method="get">
        <input type="text" name="name" />
        <input type="text" name="g-recaptcha-response" id="g-recaptcha-response" />
        <input type="submit" value="submit" />
    </form>

<script>
$(document).ready(function(){
    grecaptcha.ready(function() {
      grecaptcha.execute('reCAPTCHA_site_key', {action: 'login'}).then(function(token) {
         console.log(token)
         $.ajax({
            url: '${pageContext.servletContext.contextPath}/robot/token',
            type : 'POST',
            dataType: 'json',
            data : {'token': token},
            success : function(result){
                console.log(result);
            },
            fail: function(e){
                console.log("fail")
            }
          });// end ajax
      });
    });
});
</script>
</body>

</html>

Google DreCAPTCHA_site_key에 할당받은 사이트 키를 넣고

서버와 ajax 통신을 위해 jQuery를 이용했다.

일단 이 상태에서 토큰이 다음처럼 받아져야 한다.

이제 Controller에서 받아 Service 단에서 google reCAPTCHA와 통신을 한다.

통신 방법은 RestTemplate을 사용했으며

Post방식으로 토큰과 비밀키 값을 전송한다.

@Service
public class RecaptchaService {

    public RecaptchaDTO token(String token) {
        String url = "https://www.google.com/recaptcha/api/siteverify";

        RestTemplate restTemplate = new RestTemplate();

        HttpHeaders headers = new HttpHeaders();
        headers.setContentType(MediaType.APPLICATION_FORM_URLENCODED);

        MultiValueMap<String, String> map= new LinkedMultiValueMap<String, String>();
        map.add("secret", "secret-key");
        map.add("response", token);

        HttpEntity<MultiValueMap<String, String>> request = new HttpEntity<MultiValueMap<String, String>>(map, headers);

        RecaptchaDTO response = restTemplate.postForObject( url, request, RecaptchaDTO.class );

        return response;
    }

}

받은 자료를 콘솔에 뿌려주면 다음처럼 나오게 될 것이다.

여기서 score를 보면 0.9라는 것을 볼 수 있다.

이는 reCAPTCHA가 사람에 가깝다는 것을 판단한 것이며

이 score를 이용하여 서비스의 동작을 통제하면 될 것이다.

참고자료

https://developers-kr.googleblog.com/2019/01/introducing-recaptcha-v3-new-way-to.html

https://dany-it.tistory.com/302

https://developers.google.com/recaptcha/docs/v3?hl=ko

 

 

Made by 꿩

'IT > 보안' 카테고리의 다른 글

[방화벽] 인바운드 & 아웃바운드  (0) 2022.01.31
OAuth  (0) 2019.06.17
SSL인증서  (0) 2019.03.21
CSRF  (0) 2018.12.25
XSS 공격과 방어  (2) 2018.10.25

#OAuth

 

 

'당신의 비밀번호는 안녕하십니까?'

 

 

이메일, 비밀번호 유출은 매우 빈번하다.

어디 조금만 가입해도 이상한 스팸메일이 날라오며

잊을만 하면

유명한 사이트에서 고객정보 유출 사건이 한번씩 터진다.

 

유명한 사이트도 개인정보 유출과 관련해서 사건사고가 많은데

잘 알지도 못하는 사이트에 개인정보를 입력하고 싶은가???

 

몇몇 사람들은 비슷하거나 똑같은 비밀번호를 사용하고

이메일도 주로 하나 또는 두 개만을 사용한다.

그런데 보안이 제대로 지켜지는 지도 모르는 사이트에

덜컥 회원가입을 하고 로그인 한다면

당신의 이메일과 비밀번호는 안전하겠는가???

 

 

이런 문제를 방지할 수 있는 것이

바로 OAuth이다.

 

위키피디아에 따르면

OAuth는 인터넷 사용자들이 비밀번호를 제공하지 않고

다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나

애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는

접근 위임을 위한 개방형 표준이다.

 

내가 생각하는 OAuth란 쉽게 말해서

인증과 허가를 대신해주는 것이라 생각한다.

 

 

예를 들어,

쇼핑몰 홈페이지가 있다고 가정해보자.

이 쇼핑몰에서 옷을 구매하여 포인트를 적립하고 싶지만

로그인을 해야한다.

게다가 기억력이 안 좋아서

항상 동일한 비밀번호를 사용하기만 한다.

그렇다고 잘 알지도 모르는 사이트에

내 비밀번호를 입력하는 것도 망설여진다.

 

이때 소셜 로그인을 하면

굳이 잘 알지도 모르는 사이트에

비밀번호 입력을 하지 않아도 되고

로그인이 간편해진다.

 

OAuth를 이용한 인증방식에 대해 알아보자.

1. 고객이 카카오 로그인을 선택하면 쇼핑몰 서버는 카카오 로그인 페이지를 전송해준다.

2. 고객은 ID와 비밀번호를 입력해 본인을 인증한다.

3. 카카오 서버는 고객을 인증완료 페이지로 redirect 시킨다.

4. 카카오 서버는 redirect하면서 authorize_code 값을 포함시키고 쇼핑몰 서버는 이것을 수집한다.

5. 쇼핑몰 서버는 authorize_code로 카카오 서버에 access token을 요청한다.

6. 카카오 서버는 쇼핑몰 서버에 access token을 발급해준다.

7. 쇼핑몰 서버는 카카오 API 서버에 access token으로 사용자 정보를 불러온다.

 

정리하자면,

사용자는 카카오에서 로그인을 함으로써 본인을 인증하고

카카오는 인증을 확인하고 사용자 정보 접근을 허가하는 token 값을 발급한다.

token 값으로 쇼핑몰 서버는 사용자 정보를 카카오에서 갖고 오게 된다.

쉽게 말해 쇼핑몰과 사용자 사이에 카카오라는 중간자 역할을 둔 것이다.

 

 

참고자료

https://ko.wikipedia.org/wiki/OAuth

http://tech.devgear.co.kr/delphi_news/449506

https://d2.naver.com/helloworld/24942

 

 

To be continued.........

 

 

Made by 꿩

'IT > 보안' 카테고리의 다른 글

[방화벽] 인바운드 & 아웃바운드  (0) 2022.01.31
[Spring] Google reCAPTCHA v3  (6) 2019.07.07
SSL인증서  (0) 2019.03.21
CSRF  (0) 2018.12.25
XSS 공격과 방어  (2) 2018.10.25

#SSL인증서



포켓몬스터 게임을 하다보면

통신교환을 해야 최종진화가 되는 포켓몬들이 있다.

나는 어떻게 하는지도 모르고

방법도 귀찮아서 통신교환을 전혀 하지 않아

후딘, 강철톤, 괴력몬 등을 한번도 키워본 적이 없다.

진화의 돌 진화나 레벨업 진화만 있었으면 좋겠다.



통신교환을 하는 것은 데이터를 주고 받는 행위이다.

근데 이 데이터를 주고 받을 때

누가 가로채거나 엿본다면 데이터가 유출된다.


HTTP 통신에서도 마찬가지이다.

HTTP 통신은 암호화되지 않은 방법으로 통신하기 때문에

데이터가 쉽게 유출된다.


HTTP의 보안상 문제점을 보완하기 위해 나온 것이 HTTPS이다.

HTTPS는 SSL 프로토콜 위에서 돌아가는 프로토콜을 말하는데

쉽게 말하자면

SSL 인증서를 이용하여 웹에서 데이터를 암호화하여 주고 받을 수 있게 해준다.

SSL 인증서의 역할은 2가지이다.

첫째, 인증서 정보를 통해서 신뢰할 수 있는 서버인지 인증하는 것

둘째, 공개키로 데이터를 암호화하는 것


우선 대칭키와 공개키에 대해서 알아둘 필요가 있다.

대칭키는 암호화, 복호화 모두 하나의 키로 가능하다.

그렇기 때문에 대칭키가 유출이 되면 암호화 하는 의미가 없어진다.


반대로 공개키는 2개의 키 쌍으로 이루어져있다.

보통 다른 사람에게 공개하는 것을 공개키

나만 알고있는 것을 비밀키라 한다.

하나의 키로 암호화를 하게 되면

복호화는 다른 하나의 키로만 가능하다.

두 개의 키 모두 암호화, 복호화가 되지만

자신의 키로 암호화한 것을 복호화할 수 없고

다른 키로 암호화가 된 것만을 복호화 할 수 있다.


공개키와 대칭키에 대해 알아봤다면

SSL 인증서의 동작과정을 살펴보자.



첫번째 과정은 핸드쉐이킹이다.

이 과정은 본격적으로 데이터를 주고 받기 전에

서로가 지원하는 암호화 방식을 알아내고

데이터를 암호화하는 세션 키를 찾는 과정이다.


클라이언트가 서버에 접속을 하게 될 때

클라이언트는 자신이 사용할 수 있는 암호화 방식과

클라이언트가 생성한 랜덤 데이터를 서버에 전송한다.


서버는 클라이언트에게 받은 암호화 방식 중 자신이 지원가능한 암호화 방식을 고른다.

그리고 다시 클라이언트에게

서버가 고른 암호화 방식과

서버가 생성한 랜덤 데이터,

비밀키로 암호화된 SSL 인증서를 전송한다.


클라이언트는 SSL 인증서가

CA에 의해 발급된 인증서인지 확인하고

이미 내장된 CA의 공개키를 이용해 SSL 인증서를 복호화한다.

복호화가 정상적으로 되었다면

해당 서버는 CA에서 인증된 SSL 인증서를 가진 서버라는 것을 인증되는 것이다.


해당 서버가 신뢰할 수 있는 판단이 되는 순간

클라이언트는 자신이 생성한 랜덤 데이터와 서버가 생성한 랜덤 데이터를 조합하여

pre master secret이라는 키를 생성한다.

pre master secret을 공개키로 암호화를 하여 서버에 보내면

서버는 pre master secret을 비밀키로 복호화를 하게 된다.


클라이언트와 서버 모두 pre master secret을 이용하여 master secret을 만들고

master secret을 이용하여 세션 키를 만들게 된다.


여기까지가 핸드쉐이킹 단계이며

다음은 핸드쉐이킹 단계에서 만들었던 세션 키를 가지고

데이터를 암호화하여 주고 받는 세션 단계이다.


세션 단계에서 사용되는 세션 키는 대칭키로 암호화와 복호화가 모두 가능하다.

이미 핸드쉐이킹 단계에서 공개키를 이용한 방식으로 세션키를 만들었기 때문에

세션키를 외부로 노출할 일은 없게 된다.


결국 HTTPS는 공개키와 대칭키를 혼합하여 사용한다.

공개키는 대칭키를 암호화하여 전달하는데 사용이 되고

대칭키는 실제 데이터를 암호화하여 송수신하는데 사용이 된다.

공개키는 많은 컴퓨팅 파워를 사용하기 때문에

실제 데이터를 암호화하여 주고받는 방식은 대칭키를 이용한 방식이 더 좋다.


데이터 전송이 모두 끝나게 되면

통신에 사용하게 된 세션키는 폐기된다.


시간이 된다면 AWS를 이용하여

SSL 인증서로 HTTPS 서버를 구축해보는 것도 좋은 연습이 될 것 같다.


<참고자료>

https://opentutorials.org/course/228/4894


To be continued.........




Made by 꿩

'IT > 보안' 카테고리의 다른 글

[방화벽] 인바운드 & 아웃바운드  (0) 2022.01.31
[Spring] Google reCAPTCHA v3  (6) 2019.07.07
OAuth  (0) 2019.06.17
CSRF  (0) 2018.12.25
XSS 공격과 방어  (2) 2018.10.25

#CSRF



CSRF는 Cross-site request forgery로 사이트 간 요청 위조라 불린다.


위키피디아의 설명에 의하면,

사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위를

특정 웹사이트에 요청하게 되는 공격이라 한다.



나만의 언어로 바꿔보자면

인터넷뱅킹에 로그인한 상태에서

메일을 들어가보니까

평소 내가 사고 싶었던 100cm 냐옹 인형을 싸게 구입할 수 있다는 광고메일이 왔어.

나는 궁금해서 링크를 클릭하겠지?

나는 냐옹 인형을 구입할 수 있는 웹사이트를 요청했지만

알고 봤더니

해커에게 돈을 송금한 요청이 보내진거지.


옥션 사례가 대표적인데

관리자가 로그인을 한 상태이고

자주 가는 사이트가 있었다.

공격자가 사이트에 악성스크립트를 넣은 글을 올렸고

관리자가 그 글을 본 순간

아이디와 비밀번호가 해커는 관리자권한을 획득했고

해커는 관리자로 로그인을 하여 개인정보 데이터를 빼내온 것이다.

XSS와 CSRF는 비슷하면서도 다르다.

둘 모두 악성 스크립트를 이용한다는 점은 동일하지만

XSS는 사용자의 화면에서 악성 스크립트가 실행되는 것이고

CSRF는 사용자 권한을 이용해 악성 스크립트를 서버에 요청을 한다는 점이 다르다.


마치

도둑이 내 물건을 훔쳐간 것과

보이스피싱처럼 내가 도둑에게 돈을 송금해 준 것

이 차이랄까?



물론 CSRF 공격을 막는 방법도 있다.

그 중 하나가 CSRF 토큰을 이용한 방법이다.

CSRF 토큰은 랜덤으로 들어가는 키값인 난수이다.


화면 호출 시 세션에 CSRF 토큰인 난수값이 저장된다.

해당 화면에 대한 요청이 들어올 때

CSRF 토큰 값과 비교해서

토근 값이 일치하면 요청을 실행하고

그렇지 않으면 해당 요청을 막는 방법이다.



앞서 언급한 예시를 이용해 설명해본다면

인터넷뱅킹에 로그인한 상태로 메일의 링크를 클릭했어

근데 그 링크는 해커에게 돈을 송금하도록 요청하는 링크야

서버에서 해커에게 송금하라는 요청을 받았는데

송금하는 화면에서 생성되는 CSRF 토큰을 검사해

근데 해커가 미리 지정한 메일의 링크에 CSRF 토큰인 난수값이 없으면

요청이 금지되는 거지


해커 입장에서는 CSRF 토큰은 난수값으로

랜덤으로 생성되므로 알 수 있는 방법이 없지

그래서 메일 링크에 CSRF 토큰값을 넣을 수가 없어

물론 천재 해커들은 뚫을 방법을 찾을 수도 있겠지만....ㅎ

내가 프로젝트를 수행하면서

CSRF 토큰을 지정하는 방법은 두가지이다.


첫번째는 input hidden으로 넣는방법

1
<input type="hidden" id="csrfToken" th:name="${_csrf.parameterName}" th:value="${_csrf.token}" />
cs

두번째는 ajax요청시 header에 csrf 토큰을 넣는 방법(javascript)

1
2
3
4
5
6
7
8
9
10
11
<meta id="_csrf" name="_csrf" th:content="${_csrf.token}"/>
<meta id="_csrf_header" name="_csrf_header" th:content="${_csrf.headerName}"/>    
    
    //여기부터는 자바스크립트 
    var csrftoken = $('#_csrf').attr('content');
    var csrfheader = $('#_csrf_header').attr('content');
 
                    //ajax에 추가해야함.
                    beforeSend: function(xhr) {
                        xhr.setRequestHeader(csrfheader, csrftoken);
                    },
cs



To be continued.........




Made by 꿩




'IT > 보안' 카테고리의 다른 글

[방화벽] 인바운드 & 아웃바운드  (0) 2022.01.31
[Spring] Google reCAPTCHA v3  (6) 2019.07.07
OAuth  (0) 2019.06.17
SSL인증서  (0) 2019.03.21
XSS 공격과 방어  (2) 2018.10.25

# XSS

XSS는 Cross-site Scripting의 약자인데 웹사이트 공격방법 중 기초적인 것에 해당된다.

XSS공격은 웹사이트에 스크립트 코드를 주입시키는 방법인데

html코드를 해석하지 않게 만들면 간단히 방어할 수 있다.


높은 이해를 위해 예시를 들어보자.

XSS 보안에 취약한 게시판이 있다고 보자.


게시판에 글을 등록을 할 때 다음과 같이 스크립트 코드를 집어 넣어 보았다.



이제 게시판에 다시 들어가 보면



자바스크립트 코드가 실행된 것을 볼 수 있다.

이러한 자바스크립트 코드를 실행을 막으려면

EL 밖에 <c:out value=' '/>태그를 씌워서

 자바스크립트 태그가 실행되지 않게 만들고

 글자 그대로 출력되게 하면 된다.



<c:out value='${값}'/>에는 디폴트로 escapeXml옵션이 true로 되어있어

출력 문자열에 HTML 특수문자(예: <, >, &, ' 또는 ") 포함되어 있을 경우

HTML을 해석하지 않고 그대로 출력되도록 해준다.

혹시나 <c:out value=' ${값}' escapeXml = false />로 입력하면

HTML 코드를 그대로 해석해서 내보내주기 때문에 주의할 필요가 있다.


XSS보안을 방어한 게시판은 다음과 같이

자바스크립트 코드가 그대로 출력되어 나온다.



예시를 위해 단순한 alert창을 띄었지만

쿠키에 들어있는 개인정보를 전송하거나

엉뚱한 곳으로 접속하게 만드는 등

악성코드가 심어져 있다면

문제를 일으킬 수 있다.

그러나 이 방법은 워낙 기초적인 거라 대부분 웹사이트들이 막았기에 걱정하지 않아도 된다.



To be continued.........




Made by 꿩

'IT > 보안' 카테고리의 다른 글

[방화벽] 인바운드 & 아웃바운드  (0) 2022.01.31
[Spring] Google reCAPTCHA v3  (6) 2019.07.07
OAuth  (0) 2019.06.17
SSL인증서  (0) 2019.03.21
CSRF  (0) 2018.12.25

+ Recent posts