왜 nestjs를 사용했는지 이유를 찾자.
오늘 아침 해킹시도가 있었다.. env파일을 찾기 위한 시도가 있었지만 ignore에 있었기에 찾지 못했다.
이런 경험을 한 후 우리의 단점을 빨리 보완해야겠다는 생각이 들었다.
1. 동화 생성이 악의적으로 무제한으로 가능하다.
2. 금액 제한이 걸려있어 일정 생성 후 생성이 안되긴 하지만 한 명의 악의적인 시도로 인해 다른 유저가 동화생성을 할 수 없게 된다.
3. 회원가입이 너무 쉽다 -> 이는 초기 회원가입을 쉽게 하기 위함이었다.
어떻게 해결해야 할까
미들웨어 사용
미들웨어는 요청과 응답 사이에서 동작하는 함수로서, 요청이 들어올 때마다 실행되므로 이를 이용해 특정 패턴의 요청을 거부할 수 있다.
import { Injectable, NestMiddleware } from '@nestjs/common';
import { Request, Response, NextFunction } from 'express';
@Injectable()
export class EnvFilterMiddleware implements NestMiddleware {
use(req: Request, res: Response, next: NextFunction) {
if (
req.method === 'GET' &&
(req.path.includes('.env') || req.path.includes('admin'))
) {
res.status(403).send('Forbidden');
} else {
next();
}
}
}
위 코드는 모든 GET 요청을 검사하여 요청 경로에 .env, admin이 포함되어 있다면 403 Forbidden 응답을 반환하며, 그렇지 않다면 다음 미들웨어로 넘어가게 된다.
이 외에도 보안을 강화하기 위해 Helmet을 사용하였다.
Nest.js에서 미들웨어를 적용하는 방법은 일반적으로 두 가지다:
1. `main.ts`에서 직접 적용하는 방법
2. `app.module.ts`에서 `configure` 메소드를 통해 적용하는 방법.
`main.ts`에서 직접 적용하는 방법은 Express.js 레벨에서 미들웨어를 적용하는 방법으로, 모든 요청에 대해 미들웨어가 먼저 실행하게 된다. 이 방법은 단순하고 직관적이지만, Nest.js의 라이프사이클 이벤트나 의존성 주입 기능을 사용할 수 없다. 반면에, `app.module.ts`에서 `configure` 메소드를 통해 적용하는 방법은 Nest.js 레벨에서 미들웨어를 적용하는 방법으로, 미들웨어가 특정 라우트나 라우트 그룹에 대해서만 실행된다. 이 방법은 더 세밀한 제어를 가능하게 하며, Nest.js의 라이프사이클 이벤트와 의존성 주입 기능을 사용할 수 있다. 따라서, 일반적으로는 `app.module.ts`에서 `configure` 메소드를 통해 미들웨어를 적용하는 것이 더 효율적이고 안전하다. 하지만 이 경우에는 `.env` 파일에 대한 요청을 차단하는 것이 목적이므로, `main.ts`에서 직접 적용하는 것이 더 적합할 수 있다고 생각한다. `.env` 파일에 대한 요청은 서버의 모든 부분에 대해 차단되어야 하므로, 모든 요청에 대해 미들웨어가 먼저 실행되는 이 방법이 더 적절하다.
'helmet'모듈을 사용하면 미들웨어를 사용하지 않아도 될까?
`helmet` 모듈은 HTTP 헤더를 설정하여 웹 애플리케이션의 보안을 향상하는 데 도움을 주는 미들웨어이다. 그러나 `helmet` 모듈은 특정 URL 경로에 대한 접근 제어나 404 에러 처리와 같은 기능을 제공하지 않는다. 따라서 `EnvFilterMiddleware` 미들웨어는 여전히 필요하다. - `EnvFilterMiddleware`: 이 미들웨어는 특정 경로('.env' 또는 'admin'이 포함된)에 대한 GET 요청을 차단한다. 이는 `helmet`이 제공하지 않는 기능이므로 이 미들웨어는 필요하다. 즉, `helmet`은 애플리케이션의 보안을 향상하는 데 도움을 주지만, 모든 미들웨어 기능을 대체하는 것은 아니다. 필요에 따라 여러 미들웨어를 조합하여 사용해야 한다.
------------------------
멘토링
질문: 파이선 서버를 둘 것인지 node기반서버로 둘 지에 대한 고민...
답변: 모델을 직접 사용하지 못한다면 사용하지 않아도 될 듯
api 만들 때 rest 규칙에 다라 만들고 잇는지...?
yes
앞으로 진행할 것들은?
웹 소켓 프론트와 연동
테스트 코드..
보안 [임팩트가 없을 수도]
클라우드 플레어
보안보다는 테스트 코드에 시간을 더 투자하는 게 좋을듯하다.
성능테스트
모니터링 - 노드용 apm
기술보다는 소프트 스킬을 많이 보는 경우도 잇다.
인성 - 서로 피드백을 주고받는 방식
프론트 ;
2d를 동적으로 하는 것은 스타트업에서 제공하는 api를 사용하는 방법을 생각해 보는 게 좋을듯하다.
얼마나 기술적인 고민을 해봤는가
문제를 만나면 문제가 생긴 스토리와 해결 방법을 기록해 두면 좋을 듯
문제 - 과정 - 해결 - 성과
어떤 문제를 만나서 어떻게 해결했는가
테스트 코드는 문서역할을 한다
- 요구사항 명세서
- 성공 실패 케이스 모두 작성해야 한다.
커밋메시지 컨벤션 공부
github flow
swagger를 적용한 것
프런트에 배려한 [커뮤니케이션 비용을 낮췄다]
정리
1. Nest.js 사용 이유 탐구:
- Nest.js를 사용한 이유에 대해 고찰하였습니다. 특히 보안과 관련된 이슈를 고려하였습니다.
2. 해킹시도 대응:
- 해킹 시도가 발생한 후, 시스템의 취약점을 파악하고 개선하였습니다. 이를 위해 요청 경로에 '.env'나 'admin'이 포함된 요청을 차단하는 미들웨어를 구현하였습니다.
3. 보안 강화:
- Helmet을 사용하여 웹 애플리케이션의 보안을 강화하였습니다.
4. 멘토링:
- 멘토링을 통해 프로젝트의 방향성을 검토하고, 향후 진행할 작업들에 대한 계획을 세웠습니다. 특히 테스트 코드 작성, 서버 성능 테스트, 문제 해결 과정의 기록 등에 초점을 맞추었습니다.
'Storify' 카테고리의 다른 글
STORIFY (0212) - Docker CI/CD (0) | 2024.02.12 |
---|---|
STORIFY (0208) - swagger 접근 제어, local docker 테스트 (0) | 2024.02.08 |
STORIFY (0205-0206) - kakao, google 로그인 추가 (0) | 2024.02.06 |
STORIFY (0202) - 유저 프로필 추가 (0) | 2024.02.02 |
STORIFY (0201) - 프로젝트 피드백 (0) | 2024.02.02 |