1211
오늘 키워드
- sql injection
- 어플의 퍼포먼스 : 소요시간 줄이고 오브젝트 풀링패턴
- 쿠키
- 리플렉션
SQL Injection
- DB와 연동된 웹 어플리케이션에서 입력된 데이터에 대한 유효성 검증을 하지 않을 경우, 공격자가 입력 폼 및 URL 입력란에 SQL 문을 삽입하여 DB로부터 정보를 열람하거 조작할 수 있는 보안약점
- 안전한 코딩기법 : preparedStatement 클래스와 하위 메소드 executeQeury(), execute(), executeUpdate() 사용
예제 : login 인증처리
- 인증처리할 때 고려할 점 (발생할 수 있는 case)
- 아이디에 해당하는 유저가 있는지
- 유저가 존재하는 경우 입력한 비번과 db의 비번이 일치하는지
- 로그인 성공
=> 위 세가지 케이스를 식별할 수 있는 로직 필요. 계층형구조 도식화
- Persistance Layer : 유저가 존재하는지 확인 -> 1번 case
- Buisness Logig : 입력받은 비번과 Persistance Layer로부터 전달받은 비번이 같은지 확인 -> 2번 case
- VO 없이 STMT로만 처리하려고 했을 때 발생할 수 있는 sql injection
- 전혀 의미 없는 아이디와 패스워드로 로그인 했는데 성공처리 되버리는 경우
- 그림과 같이 입력했을 때, 로그인성공하면서 member 테이블의 데이터를 삭제해버릴 수도 있음
- 막는 방법
- 입력데이터 검증 : validate 체크
- preparedStatement 클래스 사용 : DAO 는 서비스 또는 컨트롤러로부터 전달받은 데이터가 검증된 것인지 알지 못함. 'OR' 또는 'DELETE' 같은 단어를 예약어가 아닌 그냥 단순 리터럴로 처리하기.
preparedStatement
- 쿼리 객체 생성 단계에서 쿼리를 먼저 컴파일
- 동적으로 쿼리에 연산자 등을 추가할 수가 없어짐.
- statement와 preparedStatement 차이 : 쿼리 실행할 때 쿼리 넘기지 않음
KISA, owasp top 10
- kisa(한국인터넷진흥원)에서 제공하는 기술안내서가이드 > 정보보호 시스템관리 > JAVA 시큐어코딩 가이드
(https://www.kisa.or.kr/public/laws/laws3_View.jsp?cPage=6&mode=view&p_No=259&b_No=259&d_No=55&ST=T&SV=)
- sql injection 은 굉장히 흔한 공격기법!
- 클라이언트가 주는 어떤 것도 절대 믿지 않기.
- owasp top 10 : 흔하게 발생하는 공격 top10
- 반드시 막아야 하는 공격
- Injection (주입)
- Broken Authentication (취약한 인증)
- Sensitive Data Exposure (민감한 데이터 노출)
- XML External Entities (XXE. XML 외부 개체)
- Broken Access Control (취약한 접근통제)
- Security Misconfiguration (잘못된 보안 구성)
- Cross-Site Scripting (XSS. 크로스 사이트 스크립팅)
- Insecure Deserialization (안전하지 않은 역직렬화)
- Using Components with Known Vulnerabilities (알려진 취약점이 있는 구성요소 사용)
- Insufficient Logging & Monitoring (불충분한 로깅 & 모니터링)
- 참고
Encode & Encrypt
부호화 (encode ↔ decode)
- 데이터를 전송하거나 저장하기 위해 시스템이 인지할 수 있는 데이터 표현방식으로 바꾸는 작업
- %23 (Percent Encoding / URL encoding), Base64
- Percent Encoding : URL에 문자를 표현하는 문자 인코딩 방법. 알파벳/숫자 등 몇몇 문자를 제외한 값은 16진수 값으로 인코딩
- Base64 : 64개의 문자로 데이터 표현
- [영어대소문자]52개 + [0-9]10개 + [+]1개 + [/]1개 = 64개
- 인코딩 : 키는 존재하지 않고, 읽을 수 있도록/인지할 수 있도록 하는 것이 목적.
- Data URI Scheme : 이미지와 같은 외부 데이터를 URI로 표현하는 방법.
- 문법
- mediatype : mime
생략시 기본값 : text/plain;charset=US-ASCII
- base64 : 데이터가 텍스트가 아닌 경우 base64로 인코딩된 데이터 필요함
- URI scheme를 사용하면 src 속성의 값으로 base64로 인코딩된 이미지 데이터를 직접 입력할 수 있음
- 브라우저가 가지고 있는 렌더링 엔진이 해석함.
base64로 데이터 표현한 목적 : 브라우저가 읽을 수 있도록 한 것
URL encoding
String plain = "플레인텍스트";
String encoded = URLEncoder.encode(plain, "UTF-8");
String decoded = URLDecoder.decode(encoded, "UTF-8");
- throws UnsupportedEncodingException
: 컴파일 에러. checked 익셉션
ex. UTF-8sdfljas 입력했을 경우
- html form data의 enctype 기본형 : application/x-www-form-urlencoded (key=value&key=value...)
- URLEncoder 클래스는 문자열을 application / x-www-form-urlencoded MIME 형식으로 변환하기위한 정적 메서드가 포함되어 있다.
Base64
encoded = Base64.getEncoder().encodeToString(plain.getBytes());
byte[] decodedBytes = Base64.getDecoder().decode(encoded);
sysout(new String(decodedBytes));
- encode(byte[] src) 사용했다면 출력했을 때 바이트배열의 해시코드가 출력됨
암호화 (encrypt ↔ decrypt)
- 허가되지 않은 유저가 데이터를 읽을 수 없도록 데이터 표현방식을 바꾸는 작업
단방향 암호화
- decrypt 불가능.
- MD5(Message Digest) -> SHA-512
- SHA512에서 SHA 뒤의 숫자는 해시키의 길이
- 다른 말로 해시함수라고 함
- 해시함수 : 다양한 입력데이터를 일정길이의 해시코드로 생성할 때 사용
MessageDigest md = MessageDigest.getInstance("SHA-512");
byte[] encrypted = md.digest(plain.getBytes());
String encoded = Base64.getEncoder().encodeToString(encrypted);
- 읽을 수 없음.
- 비번인데 까먹었다 ? 새로 만들어야됨. 비밀번호 변경하는 링크 주는 경우 생각
양방향 암호화
- 1) 대칭키(비밀키) : 암복호화에 동일한 비밀키 사용
- AES
- 단점 : 암호문과 키를 한 세트로 보내는데 중간에 누가 가로챈다면 ?
- 보완방안 -> 비대칭키방식
- 2) 비대칭키(공개키) : 공개키와 개인키로 구성된 한 쌍의 키로 암복호화 수행
https://docs.oracle.com/javase/8/docs/technotes/guides/security/StandardNames.html#MessageDigest
- 암호화를 정교하게 하기 위해
- 비둘기집에 충돌을 발생하지 않기 위해 ??
- 12마리 비둘기 불러몽르 건데 비둘기집 10개. 2마리는 한집에 두마리 들어가야됌(충돌)
- 해시함수 길이를 길게 하던지
- 입력 길이를 제한하던지
- 비번에 왜 단방향만 쓸까 ?
- 양방향 ->대칭키(비밀키)
AES : 블럭암호화 수행
난이도 있음 상식으로만
블럭암호화 ?
블럭 : 입력받은 데이터를 일정길이의 블럭으로 쪼갬
블럭 하나의 길이 ? 예를 들어 블럭하나 64bit면 두개의블럭
ECB
CBC =
만약에 입력문자가 130bit면 블럭 세개
양방향 공개키 2048
URLEncoder 사용하면서 길이 바껴버림
점심묵고 base 64 로
RSA 는 AES 보다 1.5배 이상의 시간이 소요됨
AES 방식의 문제 : 비밀키 하나로 암복호화 하기 때문에 키 공유 해야됨 . 반대편에 데이터, 키 모두 넘겨야됨
키 분배의 문제
비대칭방식은 키 한쌍. 시간이 오래 걸림
실제 필드에서 한가지방식의 암호화만 사용하진 않음
상식으로 아라ㅜ두자
https
우리 서버는 신뢰할수 있는 인증기관이 아니라서 https 를 사용하지 못하던 것 ..
https 사용가능하게 하는 openSSL 이라는 프레임웍으로 가상의 인증서를 발급해주ㅓ
2. 퍼포먼스
- 손님이 주문하자마자 칼국수반죽을 해 ?!
- 웹어플의 이용자는 평균 0.2초 이상 기다리지 않아
- 어느 구간이 칼국수반죽 구간인지 찾아내야됨
- 레이턴시타임, 프로세싱타임
3티어 구조 상에서
명령발생 -> 미들티어 사이
미들티어 -> DB 사이
(사이에 network 바다 )
end-start < 0.2초
소요시간의 구성요소
1. 네트워크 타야되는 지점의 소요시간 : Latency time - 네트워크때문에 발생하는 지연시간
2. 미들티어 CPU의 성능 : ProcessingTime
개발자가 어쩔수 있는 구간 (우리가 고려해야할 소요시간은 2(미들티어),3(미들티어-db간)-통칭 서버)
칼국수 반죽 구간은 3번.
미들티어와 db간의 통로 개설 과정(커넥션생성과정) = pooling 시스템 적용
pooling 안 썼을 때
- 스트링 콘캣대신 스트링버퍼나 스트링빌더 사용하는 이유
스트링은 상수풀(?) 에 적재되ㅡㄴ데, 상수풀은 가비지 컬렉터 안됨
스트링버퍼,빌더는 힙메모리에 저장. 가비지 컬렉터 시켜서 자원회수 가능
- 공간을 기준으로 성능을 향상시키기 위해 썼던 방법
- 이번에는 소요시간을 시간을 기준으로.
- 소요 시간 (response time) : latency time + processing time
- 둘 중 지배적으로 시간을 소요하는 녀석 체킹
DBCP
http://commons.apache.org/proper/commons-dbcp/
이 소스 뜯어보기
https://git-wip-us.apache.org/repos/asf?p=commons-dbcp.git;a=blob;f=doc/BasicDataSourceExample.java;h=81b6e389c57fe1f4ca42af58fdcb668e3c1aaaa7;hb=HEAD
풀링왜 쓰냐! 퍼포먼스! 소요시간! 키워드 끼워넣어서 문장 만들수 있어야 됨
기타
int 와 Integer
- DB의 테이블 구조에 따라 VO 설계시 int 대신 Integer 사용한 이유
- int 와 Integer 의 차이
- 기본형과 객체 참조형 : null 을 받을 수 있는지 없는지 차이 (기본형 int : null 불가능)
- 조회의 결과는 객체참조형으로 돌아옴.
- ex. queryForObject
- JDK 1.5 부터는 오토박싱/언박싱이 가능하기 때문에 Object를 int로 캐스팅이 가능했지만 원래 그러면 안됨.
코드 조각
- 자주 사용할 것 같은 코드를 코드 조각으로 저장하기
- 사용방법 : 보기 -> 코드조각 -> 코드조각 선택 후 드래그앤 드랍