웹 애플리케이션의 보안을 위해 사용할 수 있는 HTTP 응답 헤더는 다양하다. 스프링 시큐리티는 자체적으로 지원하는 여러 HTTP 응답 헤더를 지원한다. 필요하다면 스프링 시큐리티에 커스텀 헤더를 설정할 수도 있다. Default Security Headers 스프링 시큐리티는 기본적인 보안을 위한 HTTP 응답 헤더의 디폴트 셋을 제공한다. Default Security HTTP Response Headers Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires:0 X-Content-Type-Options: nosniff Strict-Transport-Security: max-age=31536000 ;..

스프링 시큐리티는 인증, 인가뿐만 아리나, 주요 취약점 공격을 보호해주는 기능을 제공한다. 대체로 기본으로 활성화되어있는데, 이 요약글에서는 해당 내용에 대한 부분을 다뤄보고자 한다. 1. CSRF(Cross Site Request Forgery) CSRF 공격이란? 다른 웹 사이트에서 인증하고 보관 중인 쿠키를, 악의적으로 조작된 웹 사이트의 폼 전송을 통해, 기존에 저장한 쿠키를 탈취하여, 개인 정보를 훔치고 악의적인 목적으로 활용하는 것을 말한다. 기본적으로 쿠키를 요청한 클라이언트의 브라우저에 저장하기에, 다른 컴퓨터로 조회하는 것은 불가능 하지만, 클라이언트를 속여서 가지고 있는 쿠키를 다른 사이트에 전송하는 방식을 통해 충분히 탈취당할 수 있다. 따라서, CSRF의 피해자는 또한, XSS 공격..

PasswordEncoder 인터페이스 단방향 변환 수행을 도와주는 인터페이스다. 이 인터페이스를 활용해서 사용자가 입력한 비밀번호를 인증 시점에서 비교할 수 있다. Password Storage History 1. 일반 텍스트로 암호 저장 이 방식은 SQL 인젝션 등의 악의적인 공격에 너무 취약한 방법이었고, 보안 전문가들로 하여금, 비밀번호를 보호하기 위해선 다른 무언가가 필요하다는 것을 깨닫게 해주었다. 2. SHA-256 SHA-256과 같은 단방향 해시를 적용하는 것이 관행이었던 시절이 있었다. 단방향 해시는, 초기에 설정한 비밀번호를 복호화 할 수 없는 무작위의 문자열의 조합으로 변형 시켜주는 암호화 기법이다. 따라서, 인증 시도시, 기존 해시 문자열과 사용자가 입력한 비밀번호의 해시 문자열을..

'실용주의 프로그래머'를 읽던 중, 결합도에 관한 이야기를 일게 되었다. 그중에서 인상 깊었던 점은, '상속은 결합을 늘린다'라는 항목을 보게 되었다. 처음엔 조금 의아했지만, 몇몇 국내 자바 기본서에는 확장(extends)을 상속이라고 정의하는 경우가 종종 있다는 점을 생각해보면, 클래스의 확장(extends)과 인터페이스의 주입(implements)을 구분해서 생각하는 게 좋을 것 같다. 따라서, 같은 기능을 하는 코드를 추상 클래스와 인터페이스를 활용한 예제를 통해, '상속세' 개념을 활용해보면 좋을 것 같다. 0. 예제 준비 추상 클래스나, 인터페이스로 추상화할 기능은 다음과 같다. 인삿말을 빌드하는 메서드 인사말을 출력하는 메서드 이 두 기능을 2가지 방식으로 추상화하여, 그 차이를 파악해보자...

RabbitMQ는 amqp 0-9-1이라는 생산자, 소비자 패턴을 기반으로 한 메시지 큐 통신을 중계해주는 일종의 메시지 브로커이다. 초기에는 RabbitMQ를 사용할 땐 수동으로 설정해줘야 하는 부분이 많았다. 하지만, 세월이 흐르면서 스프링 진영에서, RabbitMQ, JMS를 비롯한 amqp 기반의 오픈소스를 직관적으로 사용할 수 있게, 추상화를 잘해주어서, 지금은 모든 걸 알지 않아도, amqp 기반의 메시지 통신을 사용하는데 필요한 러닝 커브를 매우 줄여준다. 하지만, 이러한 편리함에 익숙해져서, 사용법만 익혀둔다면, 나중에 디버깅을 할 때 매우 헤맬 수 있다. 이번 게시글에서는 그러한 요소들 중에서 @RabbitListener를 사용하여, 메시지를 소비하는 기능을 구현할 때 조심해야할 점을 짚..

프로그래밍 언어의 추상화 수준은 점점 높아질 것이다. (스프링 부트, 장고와 같은 프레임워크를 보면 알 수 있다.) 코드는 결국 요구사항을 표현하는 언어라는 사실을 명심하자. 나쁜 코드 대중적으로 아무리 인기가 많은 애플리케이션을 만들었어도, 회사를 망하게 하는 원인 중 하나는 나쁜 코드이다. 나쁜 코드를 짜는 이유는 다양하다. 귀찮았거나, 바쁘거나... 그래서 우선 대충 짜 놓고 나중에 개선하기로 미루는 경우가 많지만, 르블랑의 법칙에 따라 그러한 나중은 결코 오지 않는다. 나쁜 코드는 아무리 인력을 투입해도 생산성은 0에 가까워진다. 새로운 인력은 기존 시스템에 적응할 시간이 필요한데, 코드가 복잡하니, 당연히 적응하는데 많은 시간이 걸릴 수밖에 없고, 이해했어도 해당 코드를 수정하는 데는 너무나 오..