JSP - 19. 보안 + 커넥션풀링 + 리플렉션

갓김치·2020년 12월 14일
0

JSP+Spring

목록 보기
20/43

member

  • pl
    • 돌아오는레코듲체가없었다
  • bl
    • 인증로직을 넣어 체크할 수 있기때문에 케이스를 여러개 넣을 수 있음
  • 비밀번호오류횟수
    • PL에서 데이터가져와서 BL에서 로직 체크하고 결과를 내보냄

vo 생성



보기 - 코드조각

SELECT 'private '||
       DECODE( DATA_TYPE , 'NUMBER' ,'Integer ', 'String ' )||
       LOWER(COLUMN_NAME)||';'
  FROM COLS
 WHERE TABLE_NAME = 'MEMBER';
  • db내 테이블구조 동적확인
    • select * from user_tables
    • select * from user_objects
    • select * from user_cols
  • int가 아니고 private Integer
    • 1) 기본형과 객체참조형의 차이를 떠올려봐라
      • 널을 허용할 수 있느냐(마일리지: null일수있음)
    • 2) 프레임워크의 데이터 최소단위: object

SQL Injection

  • statement 객체이용했을때 발생하는 문제점
    • ' OR '1'='1
    • 데이터 검증을 잘 안했기때문에 or이라는 키워드가 들어가있던걸 못막은 것
    • ' OR '1'='1' DELETE FORM MEMBER WHERE '1'='1

방지

1) 입력 데이터 검증 : validation을 빡세게

  • 클라이언트단, 서버단

2) prepared statement

  • PreparedStatement: 컴파일이 이미 되어있는 쿼리객체
    • Statement: 쿼리실행하며 동적 컴파일을 진행
    • PreparedStatement: 미리 컴파일이 되어있고 쿼리실행단계에서 데이터를 넣어서 넘김
  • 입력데이터 검증은 컨트롤러 역할이기때문에 dao에서는 이게 검증된건지 아닌지 모름
    • -> dao는 dao나름대로의 규칙이 있어야함 -> or나 delete를 예약어가 아닌 일반리터럴로 처리

참조문서

부호화 Encode/Decode

  • 데이터를 전송하거나 저장하기 위해 시스템이 인지할 수 있는 데이터 표현 방식으로 바꾸는 작업
    • URL인코딩에서 시스템은 NETWORK, BASE64에서는 시스템이 AI엔진
  • 키가 존재하지않음 -> 누구나 읽고 쓸 수 있음 = 제한이 없음

종류

  • Percent Encoding / URL Encoding
    • RFC-2396 기준
  • Base64
    • 64개의 문자: 영문대소문자+숫자+더하기+나누기
    • 이진데이터를 문자열로 바꿀때사용

data scheme

data scheme 위키피디아

<img src="data:image/png;base64,iVBORw0KGgoAAA
ANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4
//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU
5ErkJggg==" alt="Red dot" />
  • data scheme: 이미지 경로는 없고, 이미지 파일을 가지고 있을때 쓸수 있음
  • base64로 인코딩한 목적: 브라우저 렌더링엔진이 읽을 수 있도록
  • application/x-www-form-urlencoded
    • x-www: www독점
    • form: form을 통해 입력한 데이터

암호화 Encrypt/Decrypt

목적

  • 허가되지 않은 유저가 데이터를 읽을 수 없도록 데이터 표현방식을 바꾸는 작업
  • 목적에 따라 알고리즘을 식별해서 사용할 수 있어야한다
  • 그럴려면 암호화 알고리즘이 어떤구조로 되어있는지 알고있어야한다
  • 용어: key, padding, cipher..

종류

단방향 암호화: 해시함수 SHA-512

대칭키(비밀키,블록암호) AES

AES 추가설명

AES/ECB방식 (가장 취약)

  • AES는 블럭을 사용, 입력받은데이터를 일정길이 블럭으로 쪼갬
    • 입력받은 데이터가 128bit
    • 블럭 하나의 길이 64bit라면 입력 받은 데이터가 블럭 2개로 쪼개짐
  • 블럭 하나하나를 대상으로 암호화를 수행한 후 암호화된 블럭두개를 합쳐서 최종암호생성
  • 각 블럭 암호화문은 서로 관련성이 없음 -> 보안에 상대적으로 취약

AES/CBC방식

  • 암호문이 나오면 다음 블럭으로 끌고가서 평문블럭과 exclusive or연산을 해서 다시 암호화를 한다
  • 앞블럭과 다음블럭이 연결이 됨
  • 그래서 block chaining 방식이라고함
  • 좀더 정교하고 복잡한 알고리즘 방식이 사용됐다 = 풀기가 어렵다

AES/CBC/PKCS5Padding

  • 130bit짜리 입력데이터가 있고 64비트의 블럭으로 쪼개면
    • -> 블럭3개 (64,64,2)
      64비트중 2비트는 데이터가있어도 나머지 62비트는 비어있음
  • 남은 공간에 어떤 문자로 채워넣을건지 정해야함
  • 맨첫번째 평문 블럭은 가상의 블럭(IV: 초기화벡터)를 두고 연결
  • 필요한거: 키, IV, 패딩값 (패딩알고리즘만 정하면 알아서들어가는 값)

공개키(비대칭키) RSA

  • 공개키와 개인키로 구성된 한쌍의 키로 암복호화 수행
  • URLEncoder, URLDecoder에서 공백한칸 = 플러스로 바뀜
  • 데이터가 커질수록 시간이 오래걸림

예시 - 다시수정할것

https ex:네이버

비밀키를 나한테 줬다?
암호화알고리즘을 두개이상 사용함
HTTPS의 Secure Layer가 어떻게 암호화구조를 설정하는지 보자

  • 로그인과정
    • 로그인 페이지 줭(요청) -> 로그인페잊 ㅣ줄겡(응답)
    • 응답데이터에 숨어있는 것이 비밀키
      • 서버에서 프라이빗키를 이용해 비밀키 자체를 암호화
      • 암호화된 키를 응답데이터에 넣어 보내는것
    • 클라이언트는 가지고있던 공개키로 복호화 수행
    • 만약 로그인응답데이터를 탈취한다면?

네이버가 사용한 다른 방식??

  • 로그인시 타이핑하며 비동기요청이넘어가고 키를 하나 받아옴
  • 이 비밀키로 암호화를 시켜 로그인시 정보를 넘김
  • 네이버에서는 복호화르랗며 발행한 비밀키와 도착한 비밀키(클라이언트의 인증서)가 같은지 확인 (정상적인 유저와같은지)
  • key.nhn

openSSL

  • openSSL
    • https을 쓸 수 있게해주는 프레임워크
    • 개발단계 일반pc에서도 가상 인증서를 만들 수 있음
  • public key를 가지려면 신뢰된 서버라는 것이 등록이 되어있어야한다
    • 가상인증서가 사용자pc에저장이 되어있어야함
    • 실제로 인증서가 저장이되어야하는 위치는 클라이언트 컴퓨터라는걸 잊지마세요

DB pw 암호화

  • 컬럼 200byte (base64로 인코딩하면 64바이트여도 1.3배커짐)

개발순서

  • 1) MemberVO
    • 의존관계에 따라 Layered Architecture를 개발하려면 의존성이 제일 없는 부분을 먼저 개발해야함
  • 2) DAO interface (Persistence Layer)
    • 협업하며 동시개발하기위해 인터페이스 분리 개발 필요
  • 3) DAO impl
  • 4) IAuthenticateService



PERFORMANCE

  • 어떻게 하면 반응시간/소요시간을 줄일 수 있을 것인가

공간 기준 성능

예시

  • 메모리 공간 효율적으로 사용하기위해 StringBuffer
    • String 사용시 constant pool에 저장되어 garbage collection이 안됨

시간 기준 성능

  • 소요 시간(response time) : latency time + processing time
한번 연결 한번 처리백번 연결 백번 처리한번 연결 백번 처리
커넥션풀링 X13ms1150ms
- 열고 닫는데 시간이 오래 걸림 ->
- 물리는 바람에 동시에 20개 이상의 커넥션 -> 에러남
18ms
커넥션풀링 O721ms -> 0ms
- 처음엔 커넥션5개만드느라 오래걸림
- 새로고침 여러번하면 0됨
23ms
- maxActive 10개로 제한
- 아무리 새로고침해도 db다운안됨
15ms

예시

  • 칼국수집에갔어요 면뽑기가 오래걸려요
  • 손님이와서 그제서야 면반죽을한다면?
  • 클라이언트는 0.2초 이상 기다리지않아요...
  • 그럼 우린 0.2초 미만으로 걸리도록 리팩토링을 해야하고, 그럴려면 그 구간을 찾아야한다
  • 면준비단계는 미리해놓고 손님이오면 1인분덜어서 바로삶아서 서빙
  • 우리한텐 어느구간일까용?

Latency Time

  • 네트워크 때문에 발생하는 지연 시간
  • 클라이언트한테 요청받아서 넘어오는데 걸리는 시간
  • 이건 어떻게 우리가 못해,, kt, skt, lg가 알아서해라

Processing Time

  • Buisness Layer 내에서 일어나는일
  • 다오에서 db로 넘어가는거
    • 여기가 칼국수반죽구간 특히 네트웤통로구간
  • 단축방법
    • pc안에 cpu의 성능을 높여요
    • 알고리즘을 잘 짜서 시간 복잡도를 해결하세요
    • 서버안의 랜선(내부네트웤)의 성능을 높여라 -> 사내네트웤시스템 보강
      • 근데 아무리 보강해도, 네트웤을타야하기때문에 시간이 오래걸림
    • 미리뽑아놓고 쓰는 pooling시스템

Connection Pooling

  • 풀링을왜쓰나요?
    • 퍼포먼스를 높이고, 소요시간을 줄이기 위해

dbcp

BasicDataSource ds = new BasicDataSource();
dataSource = ds;
ds.setDriverClassName(driverClassName);
ds.setUrl(url);
ds.setUsername(user);
ds.setPassword(password);
// 풀링 정책 결정
ds.setInitialSize(initialSize);
ds.setMaxWaitMillis(maxWait);
ds.setMaxTotal(maxActive);
initialSize=5
maxWait=2000 (2초기다리장)
maxActive=10 (2초기다리고 더만들어 근데10개까지만만들어)
  • 세션보다 더 많은 수의 커넥션 요청이 발생해도 db스탑 될 일 없다
    • 최대10개까지만, 그 안에서 해결

dbcp 참고자료

REFLECTION

profile
갈 길이 멀다

0개의 댓글