IE 8 ㅡㅡ;; "교차"라는 말도 맞긴 하지만, 은근히  애매한듯...

자, 이제 크로스사이트 스크립팅(XSS)에 관하여 정리해보자.

날도 뻐근하고, 봄이면.. 잠만 퍼질러 자는 체질이라.. 너무 놀았네..

XSS사이트 스크립트의 일반적인 공식에 대해서 알아보겠다..

웹 사이트를 들어가보게 되면, 기본적인 게시판, 메일등 사용자가 직접 올릴수 있는 부분이 한개씩은 있기 마련이다.

위의 그림이 XSS의 기본적인 그림을 그린것이다.

1. 공격자는 서버에게 타겟(불특정 다수)이 읽을수 있도록, 내용과 악성 스크립트를 포함시킨 코드를 올리게 된다.

2. 타겟은 글을 읽음으로서, 공격자에게 자신이 의도치 않은 쿠키값을 전송하게 된다.

3. 쿠키 정보를 수집한 공격자는 타겟의 계정과 동일하게 모든 권한을 가지게 된다.

[ 쿠키(Cookie) ]

- 사용자가 어떠한 웹서버의 접속을 요청하게 되면, 로컬 시스템은 쿠키값을 참조하여 접속하게 된다.

   기존의 사이트 쿠키값이 없을 경우, 웹 서버에 접속하게 되면 자신의 시스템에 4kbyte이하의 쿠키값이 생성한다.

   쿠키값은 사용자의 브라우저의 정보를 쿠키값에 지정하게 되며, Windows_Server에서의 경로를 표시하였다.

각각의 포함된 쿠키값은 Web_Server별로 정리되어져 있으며, 사용자 ID와 접속 서버로 이루어져 있다.

일반적으로 확인하게 되면, Domain Name Server / 구분 ID(숫자) / 쿠키만기일 등의 구조로 이루어질 것이다.

그렇다면?? 왜 쿠키값이 위험한 것일까??

쿠키는 일반적으로 위의 정보를 제외한, 접속자의 개인 정보까지 포함되어 있어 취약점으로 발전해온 것이다.

내가 만약 네이버에 접속하였을 경우, 그에 대한 ID와 PW는 쿠키값이 포함되어져 있다.

네이버에 처음 접속하였다고 하자. 그렇다면 네이버 서버에 접속하게 되면, 4kbyte이하의 쿠키값이 접속 호스트에 저장이 될것이며,

그에 대한 쿠키값은 다음 접속시 접속할 서버는 쿠키값을 가지고, 파악하게 된다.

쿠키값은 접속 종료시 즉각, 정보가 사라지는 것이 아니다.

간혹가다 사이트 계정으로 접속하여, 브라우저를 끄고, 다시 접속해보면 기존의 ID계정으로 접속해있는 것을 보았을 것이다.

[ 쿠키(Cookie)의 중요성 ]

1. 사용자의 계정 정보

2. 자주 방문하는 서버의 정보

3. 장바구니 시스템(물건 구매시 쿠키값에 남는 현상)

    위와 같은 것들이 일반적인 쿠키의 적용 방식이다.

[ XSS 공격 특성 ]

- 기본적인 설명은 위에서 하였으므로, XSS에 대해서 더욱더 들어가보자.

[ 공격 순서 ]

1. 게시판과 같은 응용 프로그램에 스크립트 작성 언어를 올려놓게 된다.(불특정 다수)

2. 파일 열람시 타겟은 자신도 모르게 쿠키값을 가로 채이게 된다.

3. 일반적으로, 공격자는 파로스와 같은 툴로서 쿠키값을 확인하게 된다.

4. 쿠키값을 이용하여, 계정 도용이 가능하다

[ 방어 대책 ]

1. 쿠키 값에 중요한 정보는 응용 프로그램 관리자가 포함되지 않도록 설정.

2. 사용자의 입력 값에대한 필터링

    <script></script> / <javascript> / document.cookie

3. HTML 태그의 미활성화(동적 웹 특성에 대한 HTML활성화.)

4. 스크립트 언어(ASP,PHP,JAVA등)의 문구를 다른 코드로 대체, 혹은 필터링

5. 가장 중요한 것은 관리자의 지속적인 점검

 자세한건 RFC2616 문서를 보세요.

(Request For Comments :

http://www.rfc-editor.org/cgi-bin/rfcdoctype.pl?loc=RFC&letsgo=2616&type=ftp&file_format=txt

http://www.w3.org/Protocols/rfc2616/rfc2616.html )

1xx : 안내코드

100 : CONTINUE

101 : SWITCHING_PROTOCOLS , 규약을 전환

102 : PROCESSING

2xx : SUCCESS에 관한 코드

200 : OK , 성공적으로 요구를 전달하였음.

201 : CREATED , 요구가 충족되어 새로운 자원을 생성하였음

202 : ACCEPTED , 요구가 접수되었으며 아직 처리가 완료되지는 않았음. (단순한 접수여부이며 처리의 성공여부는 아님)

203 : NON_AUTHORITATIVE Information , 인증되지 않은 정보 (서버에서 사용하도록 정의되지 않는 정보세트를 말함)

204 : NO_CONTENT , 클라언트 요구을 처리했으나 전송할 데이터가 없음

       (기존내용의 변화없는 추가적인 정보입력을 실행할 경우에 해당함)

205 : RESET_CONTENT , 내용을 reset

206 : PARTIAL_CONTENT , 부분적으로 요구를 완료하였음.

207 : MULTI_STATUS

3xx : REDIRECT에 관한 코드 (처리를 위해 추가적인 동작이 필요함)

300 : MULTIPLE_CHOICES , 복수 선택

301 : MOVED_PERMANENTLY , 요청한 자원이 영구한 URI가 할당되어 이동함.

302 : MOVED_TEMPORARILY , 요청한 자원이 별도의 임시 URI에 할당되어 이동함.

303 : SEE_OTHER , 다시 다른것을 참조함.

304 : NOT_MODIFIED , 별다른 변경이 없이 응답되었음

305 : USE_PROXY , 요청된 자원은 프락시를 통해야만 접근이 됨

306 : TEMPORARY_REDIRECT

4xx : CLIENT_ERROR에 관한 코드 (요구 메시지가 처리할 수 없을 때)

400 : BAD_REQUEST , 클라이언트의 요청을 서버가 이해하지 못함.

401 : UNAUTHORIZED , 요청에 대한 응답이 사용자인증을 필요로 할 경우.

402 : PAYMENT_REQUIRED  , 예약되어 있음

403 : FORBIDDEN , 금지됨 (요청은 이해하였으나 금지되어있는 요청임)

404 : NOT_FOUND , Request-URI를 찾을 수 없음

405 : METHOD_NOT_ALLOWED , URI에서 사용되지 않는 method를 요청함.

406 : NOT_ACCEPTABLE , 접수할수없음을 나타냄.

407 : PROXY_AUTHENTICATION_REQUIRED , 프락시에서 먼저 인증을 해야함.

408 : REQUEST_TIME_OUT , 요청한 시간내에 응답을 하지 못함.

409 : CONFLICT , 충돌 (어떠한 부분의 충돌로 응답하지 못함)

410 : GONE , 영구적으로 사용할 수 없는 경우에 해당하며 그렇지 않으면 401로 응답함.

411 : LENGTH_REQUIRED , 유효하지 못한 Content-Length로 요청을 하였음.

412 : PRECONDITION_FAILED , 전체조건 실패 ( 하나이상의 Request-Header에 기재된 내용이 실패됨)

413 : REQUEST_ENTITY_TOO_LARGE , 요구 entity가 너무커서 처리가 거부됨.

414 : REQUEST_URI_TOO_LARGE ,URI길이가 허용보다 커서 처리가 거부됨.

415 : UNSUPPORTED_MEDIA_TYPE ,  지원되지 않는 포맷으로 거부됨.

416 : RANGE_NOT_SATISFIABLE

417 : EXPECTATION_FAILED

422 : UNPROCESSABLE_ENTITY

423 : LOCKED

424 : FAILED_DEPENDENCY

5xx : SERVER_ERROR에 관한 코드 (서버가 요청을 처리하는 과정에서 문제발생)

500 : INTERNAL_SERVER_ERROR , 내부서버 오류 (잘못된 스크립트 실행과 같은 예상하지 못한 오류일 경우)

501 : NOT_IMPLEMENTED , 구현되지 않았음 (요청을 처리하는데 필요한 기능이 구현되지 않았음)

502 : BAD_GATEWAY , 나쁜 게이트웨이 (게이트웨이 서버가 올바르지 않은 응답을 수신 할 경우)

503 : SERVICE_UNAVAILABLE , 과부하 또는 여러가지 이유로 현재 요청을 처리하지 못함.

       (임시적이며 일정한 시간뒤에 정상적으로 서비스 가능)

504 : GATEWAY_TIME_OUT , 게이트웨이(또는 프락시)서버가 시간내에 요청의 처리를 완료하는 수신을 받지 못함.

505 : VERSION_NOT_SUPPORTED , 지원되지 않는 HTTP 버젼임.

506 : VARIANT_ALSO_VARIES

507 : INSUFFICIENT_STORAGE

510 : NOT_EXTENDED

601 : 접근불가. HTTP CONNECT TIMEOUT

ㅇ 3초내에 CP로 HTTP Connection을 하지 못한 경우

   (예) Network 이상, CP의 과부하로 인해 CP Web서버로 connection이 안될 때)

JBoss에서 DataSource 설정 절차

(1) JDBC 라이브러리 설치

     해당 DB 벤더의 JDBC 라이브러리를 $JBOSS_HOME/server/<instance>/lib 디렉터리에 복사한다.

     절대로 어플리케이션과 함께 패키징해서는 안된다. 예를 들어 ojdbc14.jar를 WEB-INF/lib에 두면 다양한 에러를 경험할 수 있다.

(2) xxx-ds.xml 작성 및 디플로이

     JBoss에서 데이터소스 설정은 파일명이 -ds.xml로 끝나는 XML 파일을 작성해 deploy 디렉터리에 두면 된다. $JBOSS_HOME/docs/examples/jca 디렉터리를 보면 벤더별 데이터소스 설정 예제들을 볼 수 있다.

이제 예제를 통해 설정항목들을 살펴본다.

먼저 root element가 <datasources>로 복수형인게 눈에 띄는데 글자 그대로 하나의 -ds.xml 파일 하나에 여러 개의 데이터소스를 설정할 수 있다.

그 하위에 <local-tx-datasource>가 선언되어 있는데 JBoss에서는 트랜잭션 유형에 따라 <local-tx-datasource>, <xa-datasource>, <no-tx-datasource>로 element 레벨에서 구분해서 데이터소스를 설정한다. 분산 트랜잭션 처리를 위해 XA를 사용한다면 <xa-datasource>를, 그렇지 않다면 <local-tx-datasource>를 사용하면 된다.

그러면 <local-tx-datasource>로 선언할 때의 기본 설정 항목부터 살펴본다.

기본 설정 항목

1) <driver-class>

 위의 example-ds.xml에서와 같이 <local-tx-datasource>를 사용할 경우에는 java.sql.Driver 인터페이스를 구현한 드라이버 클래스를 <driver-class>에 설정한다.

2) <connection-url>

 DB접속 URL을 명시한다.

3) <jndi-name>과 <use-java-context>

 JNDI에서 데이터소스를 찾을 때 사용할 이름으로 jdbc/xxx 형식을 사용하는 것을 권장한다.

주의할 점은 데이터소스는 JNDI에 바인딩될 때 java: 네임스페이스로 바인딩된다는 점이다. 이때문에 Context.lookup()시에 java:/jdbc/xxx와 같이 명시해야 데이터소스를 찾을 수 있다.

만약 WebLogic에서 처럼 global하게 바인딩하려면 <use-java-context>false</use-java-context>로 설정하면 된다. 이 때는 Context.lookup()시에 jdbc/xxx로 명시한다.

4) <user-name>과 <password>

 DB 접속 계정과 패스워드를 명시한다. 패스워드를 따로 암호화할 필요가 있다면 이전 포스트를 참고한다.

5) <transaction-isolation>

트랜잭션 격리 레벨을 설정한다. TRANSACTION_NONE, TRANSACTION_READ_UNCOMMITTED, TRANSACTION_READ_COMMITTED, TRANSACTION_REPEATABLE_READ,
TRANSACTION_SERIALIZABLE 중에서 DB에서 지원하는 레벨을 설정할 수 있다.

Connection Pool 크기 설정

1) <min-pool-size>

 Pool에 유지할 최소 connection 개수로 기본값은 0. 기본적으로 최초 getConnection() 호출전까지 물리적인 db connection은 만들어지지 않는다. 데이터소스 디플로이시에 <min-pool-size>만큼 connection을 만들고자 한다면 <prefill>true</prefill>을 추가로 설정해준다.

2) <max-pool-size>

 최대 connection 개수를 설정한다. 기본값은 20.

각종 Timeout 설정

1) <blocking-timeout-millis>

 모든 connection이 사용중일 때 getConnection()에서 connection이 반환될 때까지 기다릴 시간으로 ms 단위이다.

2) <idle-timeout-minute>

 pool에서 일정 시간동안 사용되지 않고 있는 connection을 닫도록 설정할 수 있는데 그 시간을 분 단위로 설정한다.

3) <query-timeout>

 query에 대한 응답을 기다리며 대기할 수 있는 시간을 초 단위로 설정한다.  트랜잭션 Timeout이 설정되어 있는 경우에는 <set-tx-query-timeout>true</set-tx-query-timeout>을 추가로 설정해 트랜잭션 timeout까지 남아 있는 시간을 query timeout으로 자동으로 설정할 수 있다.

Connection 에러 처리 설정

1) <check-valid-connection-sql>

 getConnection()시 pool에서 어플리케이션에 connection을 반환하기 전에 connection 상태를 체크하는데 사용할 SQL을 명시한다.

 ex) SELECT 1 FRORM DUAL

2) <valid-connection-checker-class-name>

 getConnection()시 pool에서 어플리케이션에 connection을 반환하기 전에 connection 상태를 체크하는 DB 벤더별 클래스를 명시한다. Oracle, MySQL에 대한 구현체가 제공된다

3) <exception-sorter-class-name>

 SQLException 발생시 connection error를 검출하는데 사용할 클래스를 명시한다. 예외가 Connection 문제로 발생한 경우 해당 connection을 close하게 된다.

4) <background-validation>

 connection 상태를 매번 getConnection()시마다 체크하지 않고 일정주기로 백그라운드에서 체크할지 여부를 설정한다. 기본값은 false이다.

5) <background-validation-minutes>

 connection 상태를 백그라운드로 체크하도록 설정한 경우 그 주기를 분 단위로 설정한다. 기본값은 10분

최적화 관련 설정 항목

1) <prepared-statement-cache-size>

 PreparedStatement를 캐쉬해서 성능 향상을 꾀한다. 기본값은 0이다. 이 값이 Oracle에 설정된 open_cursor 값 보다 크면 ORA-01000 "maximum open cursors exceeded"가 발생할 수 있다.

Connection 초기 설정

1) <new-connection-sql>

 새로 물리적인 connection을 생성할 때 마다 수행할 SQL을 설정한다. DB session 설정이 필요한 경우 유용하다.

  ex) <new-connection-sql>ALTER SESSION SET nls_date_format="YYYY-MM-DD HH24:MI:ss"</new-connection-sql>

What does the message "Closing a connection for you" mean?

It means you are not closing your connections to return them to the pool. To avoid connection leaks you should have code like the following:

Connection connection = dataSource.getConnection();
try
{
// DO WORK
}
finally
{
   try
   {
       connection.close();
   }
   catch (Throwable ignored)
   {
   }
}

For jdbc you should do the same thing for Statements and ResultSets. Normally Statements are closed when the Connection is closed, but connection pooling means the close does not happen. Similarly, if you have prepared statements in a cache, ResultSets need to be closed.

Thread Local Patterns

Many persistent frameworks (hibernate/ojb) open and close connections "at random". i.e. As far as JBoss is concerned it looks like one ejb allocated the connection and another closed it.

The connection close checking does not understand this behaviour. It expects the same ejb that allocated the connection to also close it.

If you use such a pattern, you can turn off this message (see below) but you are on your own when it comes to detecting connection leaks. From 3.2.6 there is a "listInUseConnections" on the CachedConnectionManager. However, there is this known issue with some transacion demarcation semantics. This is not really a JBoss use, more that ThreadLocal patterns bypass J2EE semantics. If you do hit the problem removing the CachedConnectionInterceptor from the conf/standardjboss.xml will workaround the spurious message. You can trust hibernate at least to close connections properly provided you are ending user transactions correctly.

Turning off Connection Close Checking

In production you don't need this checking. Hopefully you have found all the connection leaks during development. You can turn it off on the CachedConnectionManager.

• transaction-service.xml for 3.2.x
• jbossjca-service.xml for 4.x

Change "Debug" to false.

  <mbean code="org.jboss.resource.connectionmanager.CachedConnectionManager" 
         name="jboss.jca:service=CachedConnectionManager">
    <depends optional-attribute-name="TransactionManagerServiceName">jboss:service=TransactionManager</depends>

    <!-- Enable connection close debug monitoring -->
    <attribute name="Debug">false</attribute>

Related

<datasources>
  <local-tx-datasource>
    <jndi-name>jdbc.dsCizle</jndi-name>
<connection-url>jdbc:mysql://xxx.xxx.xxx.xxx:3306,xx2.xx2.xx2.xx2:3306/ticketbox?failOverReadOnly=false</connection-url>
    <driver-class>com.mysql.jdbc.Driver</driver-class>
    <user-name>xxxx</user-name>
    <password>xxxx</password>
    <min-pool-size>10</min-pool-size>
    <max-pool-size>100</max-pool-size>
    <blocking-timeout-millis>5000</blocking-timeout-millis>
    <idle-timeout-minutes>15</idle-timeout-minutes>

<check-valid-connection-sql>select '1'</check-valid-connection-sql>
    <exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter</exception-sorter-class-name>
    <metadata>
       <type-mapping>mySQL</type-mapping>
    </metadata>
  </local-tx-datasource>

</datasources>

JBoss Cluster domain을 구성하던 중 불필요한 기능을 없애야 해서 뺀 도메인을 첨부합니다.

- Clustering
- Web Application(Web Container)
- JMX

위의 것을 남기고 모두 없앴습니다.
- CORBA IIOP
- JMS
- SNMP
- Client Deployer 등등

conf.jar

Attache : Domain Configuration - Server/conf directory

JBoss level에서 엄격하게 스펙을 적용하는 통에.. 위의 url-pattern은 * 이 아니고 /* 이어야 합니다.