Chapter.12
세가지 유형 해커들
- Impersonator (임퍼스네이터) : 자신을 다른 사람처럼 속이는 녀석
- Upgrader(업그레이더) : 자신의 등급을 속이는 녀석
- Eavesdropper(이즈드롭퍼) : 중요한 정보를 몰래 훔쳐보는 녀석 --> 가장 나쁜 형태의 해커
서블릿 보안의 4요소
- 인증(Authentication)
- 인가(Authorization)
- 비밀보장(Confidentiality)
- 데이터 무결성(Data Integrity)
HTTP 환경에서 인증
- HTTP 401 (Unauthorized) 응답 보내서 사용자의 암호와 패스워드를 요구 한다.
- 컨테이너가 보안 테이블을 확인 하여 주어진 ID와 PWD 올바르면 해당 자원을 보내 준다.
인증, 인가에 컨데이너의 하는 일
- 요청 자원에 대한 검색(lookup) 작업 : 보안 정보에 대해서
- 인증 작업을 합니다. : 클라이언트에게 인증 정보를 요청
- 인가 작업을 함 : 사용자가 자원에 대한 권한을 확인 한다.
보안 관련 제약 사항을 선언적으로 관리하는 이유(DD)
- XML은 사용하기 용이하므로
- 서블릿을 좀 더 유연하게 작성할 수 있으므로
- 유지보수가 쉬우므로
서블릿 보안 관련 체크 사항
보안 개념
|
책임 소재
|
복잡도
|
노력 정보
|
인증
|
관리자
|
중간
|
높음
|
인가
|
(대부분) 배포자
|
높음
|
높음
|
비밀 보장
|
배포자
|
낮음
|
낮음
|
데이터 일관성
|
배포자
|
낮음
|
낮음
|
tomcat-users.xml 파일
<tomcat-users>
<role rolename=”Guest”/>
<role rolename=”Member”/>
<user name=”Bill” password=”coder” roles=”Member, Guest”/>
…
</tomcat-users>
|
인증 활성화 하기 (DD)
<login-config>
<auth-memthod>BASIC</auth-memthod>
</login-config>
|
인가 단계
- 인가 단계 1 : 역할(role) 정의 하기
<security-role>
<role-name>Admin</role-name>
<role-name>Member</role-name>
<role-name>Guest</role-name>
</security-role>
<login-config>
<auth-memthod>BASIC</auth-memthod>
</login-config>
------------------------
관련항목 설정
|
- 인가 단계 2 : 자원/메소드 제약 정의 하기
<security-constraint>
<web-resource-collection>
<web-resource-name>UpdateRecipes</web-resource-name>
<description>선택 사항</description>
<url-pattern>/Beer/AddRecipe/*</usrl-pattern>
<url-pattern>/Beer/ReviewRecipe/*</usrl-pattern>
<http-method>GET</http-method>
<http-method>POST</http-method>
-------------------------------
항목으로 정의한 자원에 대한 제약을 걸 HTTP 메소드를 정의 하라
GET와 POST에 대해서만 제약 유효 하고 그외 메소드에 대한 누구던지
접근 가능 하다.
먄악 정의 하지않으면 모든 메소드에 다 제약을 건다는 의미
</web-resource-collection>
<auth-constraint>
<role-name>Admin</role-name>
<role-name>Member</role-name>
</auth-constraint>
------------------
정의된 자원에 대해 http-method 수행 할 group
</security-constraint>
|
웹은 자원 단위의 제약이 아니라 HTTP 요청단위의 제약을 거는 것입니다.
<role-name> 규칙
- 만약 <auth-contraint>에 <role-name>이 없다면 어떤 사용자도 접근 할 수 없다.
- <role-name>*</role-name> 모든 사용자가 다 접근 가능하다.
- <role-name> 대소문자구분
<auth-contraint> 규칙
- 옵선 항목
- 항목이 있다는 말은 관련 URL에 대하여 인증 실시하고 컨데이너에게 지시함.
- 없다면 URL에 대하여 인증 없이도 접근할 수 있다는 것
- 안에 <description> 가능 함.
- <auth-contraint/> 와 공태그는 정 반대 입니다.
- 이 옵션에 의해서 자원에 접근하지 못해도 Request Dispatcher를 통해서 가능하다.
HttpServletRequest에 프로그램적인 보안과 관련된 3개 메소드
- getUserPrincipal() : EJB에 사용 (관련 무)
- getRemoteUser() : 인증이 되어는지 안 되었는지 확인하는 메소드. 잘 사용안함.
- isUserInRole() : 메소드 내에서 인가관리(권한관리)를 함.
isUserInRole() 동작 방식
- 호출하기 전, 반드시 인증을 거쳐야 함. (인증하지 않으면 false)
- 컨데이너가 인자로 넘어온 값(“rolename”)과 정의된 사용자 역할과 비교 합니다.
- 사용자가 해당 역할이라고 한다면, 참(true)를 리턴함.
서블릿 코드
if(request.isUserInRole(“Manager”)){
----------
배포서술자에 <security-role-ref>의 <role-name>와 같음.
…
}
배포 서술자
<web-app...>
<servlet>
<security-role-ref>
<role-name>Manager</role-name>
<role-link>Admin</role-link>
----------------------------
<security-role>의 Admin와 서로 맵핑함.
</security-role-ref>
...
</servlet>
</web-app>
<web-app...>
<security-role>
<role-name>Admin</role-name>
<role-name>Member</role-name>
</security-role>
</web-app>
** 만약 <security-role-ref>와 <security-role>에 동일한 이름이 있다면 ~-ref 우선임.
|
4가지 인증 방식
- BASIC : 암호하지 않은 인코딩한(base64) 형식을 전송 , 약한 인증 방식
- DIGEST : 안전한 형태 , 암호화 매커니즘을 사용함. J2EE 컨데이너에서 반드시 지원해야 하는 방식 아님.
- CLIENT-CERT : 공인키 인증(PKC) 사용. 매우 안전한 방식으로 전송 클라이언트 인증서 가져야 함.
보통 비즈니스 환경에서 사용 - FORM : 자신만의 로그인 폼을 제공. 4가지 보안 방식중 가장 약함. 암호화되지 않은 채 전송됨.
설정
<web-app..>
<login-config>
<auth-method>BASIC | DIGEST | CLIENT-CERT | FORM</auth-method>
</login-config>
FORM 일때만
[
<form-login-config>
<form-login-page>/loginPage.html</form-login-page>
<form-error-page>/loginError.html</form-error-page>
</form-login-config>
]
…
</web-app>
|
폼 기반 인증 - 해야 할일
- DD에 <login-config> 정의 하기
- HTML 로그인 폼 생성
- HTML 오류 페이지 생성
HTML 로그인 폼과 컨테이너간 데이터 공유를 위한 3가지 항목 (반드시 아래 이름으로 사용해야 함.)
- action 명 : j_security_check
- user 명 name 속성 : j_username
- pwd , name 속성 : j_password
인증 방식 정보 표
유형
|
스펙
|
데이타 무결성
|
주석
|
BASIC
|
HTTP
|
Base64 - 약함
|
HTTP 표준, 모든 브라우저가 지원
|
DIGEST
|
HTTP
|
좀더 강력한 방식 - SSL 만큼은 아님
|
HTTP ,J2EE 컨테이너에서 옵션 사항임.
|
FORM
|
J2EE
|
가장 약함, 암호화 안됨
|
사용자 정의 로그인 화면 지원
|
CLIENT-CERT
|
J2EE
|
강력함 - 공인키(PKC)
|
강력하지만 사용자가 인증서를 가지고 있어야 함.
|
안전하게 데이터 전송하기 : HTTPS가 답입니다. 실전에서는 대부분 SSL 기반에 HTTPS를 사용함. (전송 계층의 방식)
데이터 기밀성과 데이터 무결성을 분리하여 선언하기
<web-app..>
<security-constraint>
<web-resource-collection>
...
</web-resource-collection>
<auth-constraint>
...
</auth-constraint>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
</web-app>
|
<transport-guarantee>에 들어 갈 수 있는 값.
- NONE : 디폴트 값. 데이터 보호를 하지 않겠다는 의미
- INTEGRAL : 전송 중 데이터가 변경되지 않음을 보장한다는 말이죠.
- CONFIDENTIAL : 전송 중 그 누구도 데이터를 훔쳐보지 않았음을 보장한다는 말이죠 (보장하기 위해서)
SSL를 사용한다.
