블로그-V3. 시큐리티 테스트

시큐리티 라이브러리를 처음 사용해보니까 테스트해보자.

localhost:8080/test라고 요청을 했는데

내부적으로 login으로 redirection 되고 잠겨있다.

시큐리티를 사용하면 모든 주소가 잠긴다.

우리가 아는 공격은 XSS, Injection 공격정도가 다인데

이런 공격은 필터로 직접 다 막아야한다.

필터는 네거티브 방식이다.

negative 방식은 너 이거 안돼, 이거 안돼

다른 건 다 돼!

positive 방식은 할 수 있는 것을 알려준다.

너 이거 해도 되고, 이거 해도 돼

나머지는 다 안돼!

근데 공격이 저거 두 개 말고도 너무 많아서

다 막는 게 좋다.

시큐리티가 하는 일이 여러 가지가 있는데

보안 필터를 작동시킨다.

다 막는 것이다.

그러면 우리는 풀 것만 풀어주면 된다.

시큐리티도 필터가 하나만 있을까?

필터 체인이 있다.

우리가 test 주소로 요청했을 때

첫 번째로 시큐리티의 인증 필터에 걸린 것이다.

나는 login 페이지를 만든 적이 없는데 나왔다는 것은

라이브러리에 내부적으로 만들어져 있다는 것이다.

일단 이 인증 필터를 뚫어보자.

로그를 확인해보면 비밀번호가 있다.

Ctrl + C로 복사하면 서버가 꺼지니까

마우스 우클릭으로 복사하자.

서버로 들어가졌고 test 요청해보면 잘 뜰 것이다.

서버가 실행될 때마다 비밀번호가 바뀌기 때문에

application-dev.yml에 아래 코드를 추가해주자.

spring:
  security:
    user:
      name: test
      password: 1234

그리고 서버를 껐다가 다시 켜서 확인해보면

id : test

password : 1234로 잘 로그인될 것이다.

다시 테스트해보고 싶을 때 주소에 직접 로그아웃 요청을 해준다.

localhost:8080/logout

미리 만들어져 있는 것이다.

우리는 이 login 페이지와 logout 페이지 디자인을 사용하지 않을 것이기 때문에

이름이 겹치게 컨트롤러에 만들어주면 안 된다!!

기본적인 시큐리티 라이브러리의 디폴트 값을 변경해주기 위해서는 config 파일이 필요하다.

커스터마이징 하는 것이다.

인터페이스를 사용하면 메서드가 너무 많은데

내가 사용하고 싶은 것만 사용할 수 있게 어댑터를 사용한다.

package site.metacoding.blogv3.config;

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;

@EnableWebSecurity // 해당 파일로 시큐리티가 활성화
@Configuration // IoC 등록
public class SecurityConfig extends WebSecurityConfigurerAdapter {
    
    @Override
    protected void configure(HttpSecurity http) throws Exception {
        
        // super.configure(http); 부모 메서드 안쓸거야!!
    }
}

이렇게 실행하면 인증하지 않아도 주소에 접근이 가능하다.

이 메서드가 인증 설정하는 메서드이기 때문이다.

http.csrf().disable();

만약 네이버에 로그인한다고 치면

폼 태그로 정상적인 요청인 로그인을 할 때는

"로그인 페이지 줘" 요청하면 네이버가 로그인 페이지를 만들어주고,

걔가 만들어준 로그인 폼 태그를 쓸 텐데,

포스트맨으로 요청하면 네이버가 만들어준 폼 태그를 사용한 게 아니다.

네이버 입장에서는 자기가 만들어준 폼 태그로 들어온 건지 아닌지 어떻게 확인할까?

어차피 디자인은 네이버에서 해줄 거니까 폼 태그에 이런 걸 붙인다.

이런 태그를 만들어서 던져준다.

<form>
	<input type="text" name="username" value="ssar%하하라면"/>
</form>

폼 태그의 밸류에 특정 구분자를 두고 하하라면이 밸류에 없는 요청은

"내가 만든 폼 태그로 요청한 사람이 아니야!"라고 요청을 거절하는 게 CSRF이다.

이게 기본적으로 시큐리티에 적용되어 있기 때문에

포스트맨으로 테스트할 수가 없어서 disable( )을 걸어주는 것이다.

CSRF(Cross Site Request Forgery) 공격!

// super.configure(http); 부모 메서드 안쓸거야!!
http.csrf().disable();
http.authorizeRequests()
     .antMatchers("/s/**").authenticated()
     .anyRequest().permitAll()
     .and()
     .formLogin()
     .loginPage("/loginForm")
     .defaultSuccessUrl("/");

이렇게 .으로 내려가면서 쓰는 메서드를

빌더 패턴이라고 한다.

이제 /s가 붙은 요청만 인증이 필요하고

다른 모든 요청은 허용한다.

지정되어있는 로그인 화면이 아닌 우리가 만든 로그인 페이지로 가게 설정하고,

정상적으로 로그인이 되면 메인 페이지로 보내주자.

개념은 결국 시큐리티는 내부적으로 필터와 인터셉터가 만들어져 있는 것이다.

필터이긴 하지만 스프링 컨테이너 내부에서 돌아가는 개념이다.

[출처]

https://cafe.naver.com/metacoding

메타코딩 : 네이버 카페

코린이들의 궁금증