'Enjoy'에 해당되는 글 177건
- 2011.06.17 [HTML5] 오픈 커뮤니티
- 2011.06.17 [VB6] 파일 쓰고 읽기 2
- 2011.06.10 [Flex/AIR]BitmapData를 PNG나 JPG로 변환하여 ByteArray로 서버에 전송하는 방법
- 2011.06.03 Java 스톱워치 Stopwatch 구현
- 2011.05.24 BlazeDS Source
- 2011.05.18 이펙트 트리거 종류
- 2011.05.18 SWF 파일 사이즈의 축소
- 2011.05.18 swf 파일크기 최소화 - framework RSL을 이용
- 2011.03.03 웹 개발시 보안 처리 사항들 - XSS (Cross Site Script)
- 2011.03.03 웹개발 시 보안체크리스트 20
[VB6] 파일 쓰고 읽기 Enjoy/etc2011. 6. 17. 09:30
FileSystemObject
[Flex/AIR]BitmapData를 PNG나 JPG로 변환하여 ByteArray로 서버에 전송하는 방법 Enjoy/FLEX2011. 6. 10. 17:04
[Flex/AIR]BitmapData를 PNG나 JPG로 변환하여 ByteArray로 서버에 전송하는 방법
로컬자원을 서버에 전송하기 위해 우리는 FileReference Class를 사용하면 된다.
FileReference로 파일을 서버에 전송하는 방법은 많이 공개가 되어 있다.
알다시피 FileReference의 browse()함수를 호출한 뒤, select 이벤트가 발생시 upload() 함수를 이용하여 선택한 로컬자원을 서버로 보낸다.
서버에서는 아주 단순하게 서버 임시 저장소에 저장된 파일을 원하는 곳에 복사하기만 하면 된다.
php의 경우 move_uploaded_file() 메소드를 사용하면 되겠다.
그럼 Flex 시행도중 캡쳐한 화면을 저장하는 경우에도 위와 같은 방법으로 저장이 가능할까?
나는 예전에 ImageSnapshot 클래스를 이용해 base64로 변환해서 서버로 전송한 뒤에 base64를 decode하여 저장하는 방법에 대해서 언급한적이 있다. (http://blog.jidolstar.com/301 참고)
이 방법의 단점은 이미지가 큰 경우 base64로 encode,
decode 하는 과정에서 서버성능 및 클라이언트 성능에 따라 속도 및 부하에 영향을 준다. 그러므로 이 방법으로는
PNGEncoder 및 JPGEncoder로 PNG, JPG 파일 형식에 맞는 데이타를 만들었다고 해도,
FileReference와 같이 데이타를 전송을 할 수 없었다.
하지만 Google을 열심히 돌아다녔다니 이 문제점에 대한 해결의 실마리를 찾을 수 있었다.
(역시 Google!!!)
간단히 방법을 요약하자면
화면을 BitmapData로 만들어 PNGEncoder나
JPGEncoder를 이용하여 encode한 다음, 그 결과값인 byteArray값을 서버에 전송한다. 전송된 데이타는
FileReference에서 upload()을 이용해 보낸 파일을 저장할때와 동일하게 저장하면 되겠다.
1. BitmapData로 캡쳐해라.
아래 target은 캡쳐할 UIComponent와 같은 DisplayObject 객체이다.
단, BitmapData를 이용해서 화면을 캡쳐할 대상이 외부 동영상이나 사진같은 거라면 crossdomain.xml 에 대한 check가 있어야 한다. 컨텐츠 로드시 checkPolicyFile 속성을 true로 설정할 필요가 있겠다.
그리고 2880px 이상의 크기는 BitmapData로 만들 수 없다.
2. JPG나 PNG로 Encode 하여 ByteArray를 얻는다.
Flex 3 SDK에는 mx.graphics.codec 패키지에 JPGEncoder와 PNGEncoder가 있다. 인터넷을 뒤져보면 GIFEncoder등도 있을것이다. Flex 2 환경에서 작업한다면 Google code에 Adobe AS3 Corelib에 이들이 제공된다. 만약 JPGEncoder를 사용한다면 다음과 같이 하면 되겠다.
Flex 3 SDK는 이러한 Encoder가 IImageEncoder로 구현되었다. 필요하다면 언제 어디서나 Encoder를 바꿔야 하는 경우 IImageEncoder를 사용하는 것이 좋을 수 있겠다.
가령 아래 예제처럼 말이다.
3. 서버에 ByteArray를 전송한다.
데이타를 전송할때는 FileReference를 사용하지 않는다.
바로 URLLoader와 URLRequest만 이용해서 전송이 가능하다. 참고 데이타는 POST방식으로 URLVariable을 이용해서 보낼 수 있다.
위에 진한 부분에 대한 클래스는 아래에 정의되어 있다. 당신은 이 클래스가 어떻게 구성되었는가 열심히 공부할 필요가 없다.(원한다면 해도 된다. 말리지 않음 ^^)
한가지 중요한 정보를 언급하겠다.
URLLoader를 이용해 서버에 전송할때, 프로그램이 같은 도메인상에 있는 경우에는 보안문제가 없다. 하지만 다른 도메인에 위치한 서버로 이미지를 전송할때는 반드시 crossdomain.xml을 check해야한다.
1. Security.loadPolicyFile(http://다른도메인/crossdomain.xml ); 를 URLLoader의 load()함수를 호출하기 전에 호출한다.
2. Flash Player 9.0.124.0 버전부터는 HTTP
Header 보안취약점을 해결하기 위해서 cross domain 정책이 변경되었는데.... 서버측에 있는
crossdomain.xml에 allow-http-request-headers-from가 추가되어져야 한다. 이것은 HTTP 헤더
전송을 허용할지 결정해준다.
위 처럼 서버측 crossdomain.xml에 allow-http-request-headers-from을 추가함으로 다른 도메인간에 HTTP 헤더 전송을 허용할 수 있다.
서로 다른 도메인에 SWF와 서버측 코드가 배치되어 있다면 반드시 이 사실을 숙지하길 바란다.
4. 서버측 코드 작성
만약 위 3번 코드에서 var parameters:URLVariables를 아래와 같이 작성했다고 하자.
그럼 PHP 코드로 아래와 같은 방법처럼 만들면 되겠다.(테스트는 안해봤음)
마지막 save Comple 메시지를 받기 위해서는 Flex의 Complete 이벤트 발생시 아래와 같은 방법으로 받으면 되겠다. 이것을 알아내는데도 많이 힘들었다. 일종의 팁이다. ^^;
실제 업무에도 잘 이용하고 있다.
이미지 에디터 등을 만들때 아주아주 유용한 자료가 될 것이다.
누가 예제 프로그램 만들어서 트랙백 걸어 주시면 고맙겠다.
Java 스톱워치 Stopwatch 구현 Enjoy/JAVA2011. 6. 3. 16:13
변수선언 :
static String timerBuffer; //경과 시간 문자열이 저장될 버퍼 정의
static int oldTime; //타이머가 ON 되었을 때의 시각을 기억하고 있는 변수
본문내용 :
oldTime = (int) System.currentTimeMillis() / 1000; // 타이머 시작
System.out.format("Timer OFF 1! 경과 시간: [%s]%n", timerBuffer); // 경과 시간 화면에 출력
시분초로 변환 함수 선언 :
public static void secToHHMMSS(int secs) {
int hour, min, sec;
sec = secs % 60;
min = secs / 60 % 60;
hour = secs / 3600;
timerBuffer = String.format("%02d:%02d:%02d", hour, min, sec);
}
BlazeDS Source Enjoy/FLEX2011. 5. 24. 18:15
출처 : http://opensource.adobe.com/wiki/display/blazeds/Source
BlazeDS Source
BlazeDS is one of several open-source projects in a Subversion repository hosted by Adobe. Subversion is an open-source revision control system used for many open-source projects. If you haven't used it before, please see the official documentation.
View the BlazeDS Source Tree
If you just wish to browse around the BlazeDS source tree, go straight to the public repository here.
BlazeDS Source Tree Organization
Within the project are directories named trunk, branches, and tags, as is standard for Subversion projects.
The trunk is generally work-in-progress on the version under current development. The trunk should build and pass basic tests but may be unstable and unsuitable for use.
Branches are created when projects need to stabilize code for a release. The BlazeDS 4 code may be found in branches/4.x and BlazeDS 3 code may be found in branches/3.x.
Tags record the code that shipped as a specific release, or other milestones in a project. The code which shipped as the 4.0 release has been tagged as tags/4.0.0.
Access the BlazeDS Source
Most users of the source code probably don't need to have day to day access to the source code as it changes. For these users we provide a zip file of the latest stable release.
- To download a zip file of the source of the latest stable release, go here
Checking out Source Code
If you feel that you need access to the source tree to get a local copy of the latest and greatest code, you will need a Subversion client. The BlazeDS team has had good experience with TortoiseSVN on Windows and SmartSVN on Macintosh, both of which are GUI clients. (This is not an official endorsement of these products by Adobe.) Of course, you can use whatever client you prefer, including Subversion's official command-line tool svn.
NOTE: The Subversion repository should only be used if you want to be on the bleeding-edge of the development effort. The code contained in them may fail to work, or it may even eat your hard drive.
When you access the repository with a Subversion client, the BlazeDS project is at the URL http://opensource.adobe.com/svn/opensource/blazeds.
To get the source code, do a "checkout" of the trunk or some branch or tag into a local directory on your machine. For example, to get the code in the trunk, checkout from the URL http://opensource.adobe.com/svn/opensource/blazeds/trunk. Using the command-line client, you would execute
svn checkout http://opensource.adobe.com/svn/opensource/blazeds/trunk <local-directory>
To get the code that was used to build the BlazeDS 4 release, checkout from the URL http://opensource.adobe.com/svn/opensource/blazeds/tags/4.0.0:
svn checkout http://opensource.adobe.com/svn/opensource/blazeds/tags/4.0.0 <local-directory>
To get the code that was used to build the BlazeDS 3 release, checkout from the URL http://opensource.adobe.com/svn/opensource/blazeds/tags/3.0.0:
svn checkout http://opensource.adobe.com/svn/opensource/blazeds/tags/3.0.0 <local-directory>
Warning: You probably don't want to check out the entire blazeds directory, as you'll get every branch and tag, each of which is comparable in size to the trunk.
Access rights
Everyone has read-only access to the BlazeDS project. If you want to contribute to the BlazeDS project, refer to the BlazeDS page on Submitting A Patch.
Change notifications
If you'd like to keep up-to-date on changes to the BlazeDS project, you may subscribe to the Commits forum.
이펙트 트리거 종류 Enjoy/FLEX2011. 5. 18. 15:44
출처 : http://loudon23.blog.me/30020039980
이펙트 트리거
addedEffect : 컴포넌트가 컨테이너에 child로 추가될 때
removedEffect : 컴포넌트가 컨테이너로 부터 제거될 때
creationCompleteEffect : 컴포넌트가 새로 생성 되었을 때
focusInEffect : 컴포넌트가 포커스를 얻었을 때
focusOutEffect : 컴포넌트가 포커스를 잃었을 때
showEffect : 컴포넌트 visible 속성이 false에서 true로 바뀌어 보이게 되었을 때
hideEffect : 컴포넌트 visible 속성이 true에서 false로 바뀌어 보이게 되었을 때
resizeEffect : 컴포넌트 크기가 변경 되었을 때
moveEffect : 컴포넌트가 이동 할 때
rollOverEffect : 컴포넌트 위에 마우스가 올라가 갔을 때
rollOutEffect : 컴포넌트 위에 있던 마우스가 컴포넌트 밖으로 나갔을 때
mouseDownEffect : 컴포넌트에 마우스 버튼으로 눌렀을 때
mouseUpEffect : 컴포넌트에 눌러진 마우스 버튼을 놓았을 때
[출처] 이펙트 트리거 종류|작성자 루든
SWF 파일 사이즈의 축소 Enjoy/FLEX2011. 5. 18. 15:40
출처 : http://loudon23.blog.me/30034697717
<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"> <mx:Button label="버튼"/> </mx:Application> |
위의 코드를 실행 해 보면 용량이 243,860 bytes 이다.
웹서비스에 올리기에는 단지 버튼 하나 들어갔을 뿐인데 용량이 꽤 크다;;
그래서 최적화 해보려고 정보를 찾아 봤다.
Flex 3 Help 내용을 보니
(http://livedocs.adobe.com/flex/3/html/performance_06.html#208825)
- 바이트 코드 옵티마이져 사용
- 디버그의 무효화
- strict 모드사용
- 링커의존 확인
- 사용하지 않는 클래스의 초기화의 방지
- 어셋의 외부화
- 매입 폰트에 대한 문자범위의 사용
이러한 방법이 있다고 한다.
그래서 하나씩 테스트 해보면서 용량 비교를 해봤다.
1. 바이트 코드의 옵티마이져 사용
바이트 코드 옵티마이져는 "플렉스 최적화 응용 프로그램의 합병과 구멍을 바이트 코드를 사용하여 swf 파일을 최적화합니다. 바이트 코드에서 중복을 제거 지침을 구멍을 최적화합니다.(The bytecode optimizer can reduce the size of the Flex application's SWF file by using bytecode merging and peephole optimization. Peephole optimization removes redundant instructions from the bytecode.)" 라고 하는데.. 뭔말인지 모르겠음;;;
사용방법 :
mxmlc -optimize=true MyApp.mxml |
용량비교
- -optimize=true : 243,860 bytes
- -optimize=false : 284,336 bytes
사용 한것과 안한 것의 차이가 40,000 bytes(약 15%) 정도 난다.
참고
optimize 옵션은 기본값이 true 상태임. 구지 mxmlc 에서 설정 할 필요 없다는 말;;
2. 디버그의 무효화
VC++ app들을 보면 릴리즈버전과 디버그 버전을 만들수 있듯, swf도 마찮가지다. 릴리즈 버전으로 제작을 하면 용량이 줄어 든다.
사용방법 :
mxmlc -debug=true MyApp.mxml |
용량비교 :
- -debug=true : 243,860 bytes (디버그 버전)
- -debug=false : 150,645 bytes (릴리즈 버전)
디버그 버전을 포함하면 93,215 bytes (약 40%) 정도 늘어난다.
참고
debug 옵션의 기본값은 mxmlc 컴파일러는 false, compc 컴파일러는 true 이다.
flex 빌더의 경우 기본값이 true이다.
* mxmlc(어플리케이션 컴파일러) - ActionScript 및 MXML 등의 원시 파일로부터 SWF만들 때 사용
* compc(컴퍼넌트 컴파일러) - 컴퍼넌트 원시 파일, 이미지, 스타일 시트등의 어셋 파일로부터 SWC 파일을 생성하는 경우에 사용
3. strict 모드 사용
strict 컴파일러 옵션을 true로 설정하면, 컴파일러는 import 된 패키지들이 사용되고 있는지를 검증합니다. import한 클래스가 사용되지 않는 경우에 컴파일러는 에러를 보고합니다. 그리고 컴파일시 타입의 체크도 실시합니다.
사용방법 :
mxmlc -strict=true MyApp.mxml |
용량비교 :
- -strict=true : 243,860 bytes
- -strict=false : 245,777 bytes
strict 모드 사용 안한것에 비해 사용 한것이 1,917 bytes (약 1%)가 줄어든다.
4. 링커의존 확인
swf파일 사이즈를 축소하는 방법을 찾아 내려면 swf 파일에서 쓰이고 있는 actionscript 클래스의 리스트들을 확인 합니다. 확인 후에 원인이되는 링커의존관계를 끊고, 새로운 코드를 작성 합니다.
사용방법 :
mxmlc -link-report 리포트파일명 MyApp.mxml |
이 옵션을 실행하면 '리포트파일명'으로 된 파일이 하나 생성된다. 해당 파일을 열어보면 swf 파일 내에서 쓰이고 있는 actionscript 클래스 리스트들을 확인 할 수 있고. 해당 클래스들의 의존관계를 볼 수 있다.
like-report 파일 내용
<script name="C:\flex3sdk\frameworks\libs\framework.swc(mx/skins/ProgrammaticSkin)" mod="1141055632000" size="5807"> <def id="mx.skins:ProgrammaticSkin"/> <pre id="mx.core:IFlexDisplayObject"/> <pre id="mx.styles:IStyleable"/> <pre id="mx.managers:ILayoutClient"/> <pre id="flash.display:Shape"/> <dep id="String"/> <dep id="flash.geom:Matrix"/> <dep id="mx.core:mx_internal"/> <dep id="uint"/> <dep id="mx.core:UIComponent"/> <dep id="int"/> <dep id="Math"/> <dep id="Object"/> <dep id="Array"/> <dep id="mx.core:IStyleClient"/> <dep id="Boolean"/> <dep id="Number"/> <dep id="flash.display:Graphics"/> </script> |
link-report 파일 내의 태그 설명
- 태그명 - <script>
- 설명 - 어플리케이션의 SWF 파일 작성에 사용되는 컴파일 단위명을 나타냅니다.컴파일 단위는 클래스, 함수, 이름 공간등의 일반 정의를 1 개이상 포함합니다.
name 속성에는 스크립트의 격납원이 표시됩니다. 원시 파일 또는 SWC 파일(frameworks.swc 등)로 나타납니다.
커멘드 라인으로 keep-generated=true 와 설정하면, 생성된 폴더의 모든 클래스가 이 파일의 스크립트로서 리스트 됩니다.
size 속성에는 클래스의 사이즈가 바이트 단위로 나타납니다.
mod 속성은 스크립트가 작성되었을 때의 타임 스탬프를 나타냅니다.
- 태그명 - <def>
- 설명 - 스크립트, 클래스, 함수 네임스페이스 등의 이름을 정의 합니다
- 태그명 - <pre>
- 설명 - 현재의 정의를 링크 하기 전에 SWF 파일에 링크 할 필요가 있는 정의를 나타냅니다. 이 태그는 전제 조건을 의미합니다.
클래스 정의의 경우, 이 태그는, 직접적인 부모클래스(flash.events:Event 등) 및 그 클래스를 구현하는 모든 인터페이스(mx.core:IFlexDisplayObject,mx.managers:ILayoutClient 등)을 나타냅니다.
- 태그명 - <dep>
- 설명 - 이 정의가 의존하고 있는 그 외의 정의를 나타냅니다(String,_ScrollBarStyle,mx.core:IChildList 등).
이것은, 현재의 스크립트가 필요로 하는 정의에의 참조입니다.
다른 정의에 의존하고 있지 않는 스크립트 정의도 존재하므로 <script> 태그에 <dep> 자식 태그가 없는 것도 있습니다.
- 태그명 - <ext>
- 설명 - 링크 되지 않았던 어셋에 대한 의존을 나타냅니다.
external-library-path,externs, 또는 load-externs 컴파일러 옵션을 사용해 어셋을 SWF 파일에 추가하면 이러한 의존관계(dependencies)가 링크 리포트에 표시됩니다.
5. 사용하지 않는 클래스의 초기화 방지
쉽게 말하자면 쓰지 않는 컨트롤을 swf에 로드 하지 마라는 말입니다.
아래의 예는 어플리케이션 전체에서 DataGrid 컨트롤이 없어도 DataGrid을 강제적으로 swf 파일에 포함하고 있습니다.
<?xml version="1.0" encoding="utf-8"?> |
용량비교 :
이것은 strict 모드로 하고 있으면 용량 비교가 되지 않는다. 이유는 위에 있는 strict를 보면 쓰이지 않는것은 애초에 포함을 안시키기 때문이다. 그래서 strict 모드를 끄고 테스트 하였다.
- 쓰지 않는 DataGrid 임포트 전 - 245,768 bytes
- 쓰지 않는 DataGrid 임포트 후 - 245,775 bytes
별차이를 모르겠음;; 테스트 잘못했는가??
6. 어셋의 외부화
Flex 어플리케이션으로 사용되는 외부화의 방법은 여러가지가 있습니다. 예를 들면, 다음과 같은 방법이 있습니다.
- 모듈을 사용한다
- 실행시 스타일 시트를 사용한다
- 런타임 공유 라이브러리(RSL)을 사용한다
- 어셋을 임베드 하지 않고 실행시에 로드한다
swf내에서 비트맵 이미지를 많이 포함 하고 있으면 당연히 용량이 커진다. 용량을 줄이기 위해서 실행시에 로드하도록 만들어야 한다.
<?xml version="1.0" encoding="utf-8"?> <mx:Image source="http://imgnews.naver.com/image/001/2008/08/13/PYH2008081400270005100_P2.jpg" /> --> |
이 코드에 보면 위에 꺼는 외부에서 불러오는것이고 아래 것은 swf에 임베드 하는것이다.
용량비교 :
- 이미지 파일의 크기 - 31,648 bytes
- 실행시 로드 - 252,853 bytes
- 어셋 매입 - 285,559 bytes
어셋 매입에 비해 실행시 로드가 32,706 bytes(약 10%) 줄었다.
7. 매입 폰트에 대한 문자 범위의 사용
매입 폰트의 쓰이는 글자 범위를 지정하여 폰트 사이즈를 작게 하는 방법이다.
문자 범위는 flex-config.xml 또는 각 MXML 파일의 font-face 선언으로 설정 할 수 있다.
문자범위는 유니코드 값을 사용하고 개별 문자 또는 문자 범위를 지정가능하다.
지정방법 :
css를 통한 방법
@font-face { |
flex-config.xml 파일을 통한 방법
<language-range> <lang>Latin I</lang> <range>U+0020,U+00A1-U+00FF,U+2000-U+206F,U+20A0-U+20CF,U+2100-U+2183</range> </language-range> |
용량비교 :
다음의 코드를 통해서 용량 비교를 테스트 했다.
<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"> <mx:Style> @font-face { src:url("../assets/tunga.ttf"); fontFamily: tunga; unicodeRange: U+0030-U+0039, /* Numbers [0..9] */ } </mx:Style> <mx:Label text="1234567890" fontFamily="tunga" /> </mx:Application> |
문자범위 지정 전 - 267,509 bytes
문자범위 지정 후 - 248,529 bytes
지정 전 보다 지정 한 후가 18,980 bytes (약 8%)정도 용량이 줄었다.
여러가지 방법이 있지만 이중에서 내가 느끼기엔 가장 효율이 좋은것은 어셋의 외부화이다. 그중에서도 특히 어셋의 외부화 - 런타임 공유 라이브러리(RSL)을 사용하는 것이다.
RSL는 공통으로 쓰는 공유 라이브러리를 런타임때 호출 하는 방식이다. 윈도우에서 따지자면 공유 DLL 같은 방식이다.
이것을 swf에 적용 한다면, FLEX에서 쓰는 Framework를 외부 파일로 빼내서 런타임때 불러서 쓰는 것이다. 뭐... 다르게 말하자면 .net framework 처럼 쓴다고 할까나?? (맞는 비유일까;;;)
[출처] SWF 파일 사이즈의 축소|작성자 루든
swf 파일크기 최소화 - framework RSL을 이용 Enjoy/FLEX2011. 5. 18. 15:38
출처 : http://loudon23.blog.me/30034706962
swf 용량을 줄이는 방법중에서 가장 나은 방법이 Flex Framework 를 런타임 공유 라이브러리(RSL)로 만드는 것이다.
RSL는 아래 그림 두곳에서 쓰는 공통되는 모듈을 하나의 모듈로 빼서 실행시에 호출 해서 쓰는 것을 말한다.
framework rsl를 만드는 방법은 간단하다.
1. Navigator 뷰에서 해당 프로젝트를 선택
2. 선택 된 프로젝트에서 마우스 오른쪽 버튼 클릭
3. Properties 선택
4. Properties창에서 [Flex Build Path] - [Library Path] 선택
5. 아래의 그림 처럼 Framework linkage 를 Runtime shared Library(RSL)을 선택
bin-debug 폴더 또는 bin-release 폴더를 보면
framework_해당버전.swf
framework_해당버전.swz
파일이 생성된것을 볼 수 있다. 두 파일의 차이점은
.swf
- 서명 없는 framework RSL
- 허가된 도메인만 해당 RSL 모듈을 사용가능
- 브라우저 캐쉬
.swz
- 서명 있는 framework RSL
- Adobe 만 제작 가능
- 도메인에 관계없이 임의의 어플리케이션에서 엑세스 가능
- 플래시 플레이어에 의해 캐쉬
여기서 플래시 플레이어 캐쉬 위치는 아래를 참조하시길...
플랫폼 | 플래시 플레이어 캐쉬 저장 장소 |
Windows 95/98/ME/ 2000/XP | C:\Documents and Settings\user_name\Application Data\Adobe\Flash Player\AssetCache\ |
Windows Vista | C:\Users\user_name\AppData\Roaming\Adobe\Flash Player\AssetCache\ |
Linux | /home/user_name/.adobe/Flash_Player/AssetCache/ |
Mac OSX | /Users/user_name/Library/Cache/Adobe/Flash Player/AssetCache/ |
이렇게 만들어진 swf 파일의 크기비교를 해보았다.
<?xml version="1.0" encoding="utf-8"?> <mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute"> <mx:Button label="버튼" /> </mx:Application> |
용량비교 :
- RSL 전 - 243,864 bytes
- RSL 후 - 72,365 bytes
- framework.swf 크기 (3.0.0.477 버전 기준) - 535,001 bytes
RSL 전보다 RSL를 적용한 후가 171,499 bytes (약 70%) 정도의 용량을 줄여졌다[출처] swf 파일크기 최소화 - framework RSL을 이용|작성자 루든
웹 개발시 보안 처리 사항들 - XSS (Cross Site Script) Enjoy/JSP2011. 3. 3. 13:47
출저 : http://cafe.naver.com/junes81/1619
XSS (Cross Site Script)
발생원인은 Cookie , Session 사용, Html TAG 사용 가능, 사용자의 입력값을 Filtering 하지 않아 발생
사용자의 입력내용을 포함하는 HTTP요청에 대해 동적으로 HTML을 생성하는 어플리케이션(CGI)이 공격대상이 됩니다.
정적인 웹페이지, 즉 일반적인 HTML로 작성된 웹페이지에서는 이 문제는 일어나지 않습니다.
보통 게시판에 글을 클릭하거나 자료를 봤을때 다른 페이지로 이동을 하거나 화면이 자동 리플레쉬가 되는 현상
이 발생합니다.
script 와 암호화 되지 않은 쿠키 정보를 그대로 다른 서버에 가져갑니다.
더욱이 피싱사고를 유발 할 수 있죠
이해를 돕기위해 간단한 예제를 보겠습니다.
그림과 같이 텍스트을 입력받는란이 있어 여기에 사용자가 임의의 문자열을 입력한후 "전송하기"버튼을 누르면 사용자의
입력한 문자열을 웹페이지에 출력해주는 cgi 프로그램이 있다고 하면 결과는 다음과 같을것입니다.
화면에서 굵은폰트속성을 나타내는 HTML 태그를 사용하여 "안녕하세요 <B>jakehong</B>님!"이라고 입력해 본다면
결과가 어떻게 나올것 같나요?
만약 다음과 같은 페이지가 표시된다면 해당 사이트는 XSS의 공격대상이 됩니다.
이렇게 된다면, 입력란에 "<SCRIPT>alert("까꿍!");</SCRIPT>"라고 입력해 보면 아래 그림과 같이 "까꿍!" 이라고
써진 다이얼로그박스가 나타납니다.
응용해서 악한 마음을 가진 사람들이 <SCRIPT> 를 이용하여 사용자의 쿠키정보나 특정사이트로의 강제 이동등의
공격을 가할 수 있습니다.
* 대처방안-------------------------------------------------------------------------------------
1. 중요한 정보는 쿠키에 저장하지 않아야 하며 사용자 식별 같은 부분은 쿠키에 담지 않아야 한다.
2. 스크립트 코드에 사용되는 특수 문자에 대한 이해와 정확한 필터링을 해야 한다.
가장 효과적인 방법은 사용자가 입력 가능한 문자(예를 들어, 알파벳, 숫자 및 몇 개의 특수문자) 만을 정해 놓고
그 문자열이 아닌 경우는 모두 필터링해야 합니다.
------------샘플코드------------------------
public static String toFilterString(String in) {
if(in == null || in.length()<1)
return in;
StringBuffer out = new StringBuffer();
for (int i = 0; in != null && i < in.length(); i++) {
char c = in.charAt(i);
if (c == '\'') {
out.append("");
} else if (c == '\"') {
out.append("");
} else if (c == '<') {
out.append("<");
} else if (c == '>') {
out.append(">");
} else if (c == '&') {
out.append("&");
} else if (c == '(') {
out.append("(");
} else if (c == ')') {
out.append(")");
} else {
out.append(c);
}
out.append(c);
}
return out.toString();
}
--------------------------------------------
이 방법은 추가적인 XSS 취약점에 사용되는 특수 문자를 애초부터 막을 수 있다는 장점이 있습니다.
3. 꼭 필요한 경우가 아니라면 게시판에 HTML 포멧의 입력을 사용할 수 없도록 설정합니다.
4. 스크립트 대체 및 무효화 javascript라고 들어오는 문자열을 무조건 'x-javascript'와 같이 대체를 하여 스크립트 실행을
무효화시키는 방법도 있습니다. -> 이 방법 보다는 < 와 > 기호를 < 와 > 로 치환하는 것이 나을 듯
웹개발 시 보안체크리스트 20 Enjoy/JSP2011. 3. 3. 13:45
Guide 1. 세션유지를 위해서 Cookie를 사용할경우, 위/변조에 대비해야 한다. |
■보안 수단없이 쿠키에 인증정보를 저장해서 사용할 경우 해당값들의 위,변조가 가능하며, 이로 인하여 다른 사용자로 위장 또는 |
권한상승 등의 문제가 생길 수 있다. 따라서 쿠키를 사용할 경우, 쿠키값의 불법 위/변조가 불가능하도록 구현해야 한다.
|
■점검방법 : 사이트에 로그인한 후, 웹브라우저의 주소창에 javascript:document.cookie; 입력해서 내용을 확인한후, |
해당 세션 쿠키를 사용하는 웹어플리케이션 소스 점검을 통해 불법 변조탐지루틴이 있는지 확인한다.
|
■조치방법 : 아래 방법들 중에서 가능한 것을 선택해서 적용함. |
1) 쿠키값 암호화를 통한 쿠키불법 변조방지(서버에서 전송받은 쿠키를 복호화 한후, 위/변조 되었는지 확인) |
2) 쿠키값에 대한 Message Digest(예, MD5, SHA-1 등) 값의 첨부 및 검증을 통한위,변조탐지(아래예제참조) |
3) 쿠키에 세션값을 저장하는 대신어플리케이션서버세션사용(사용하는웹어플리케이션서버가지원하는지확인필요) |
<php 예제> |
$secret_word = ‘lgcard_secret_value’; |
// 쿠키설정하기 |
$id = ‘lgcard’; |
$hash = md5($secret_word . $id); |
setcookie('id', $id . '-‘. $hash); |
// 받은 쿠키가 변조되었는지 확인하기 |
list($cookie_id,$cookie_hash) = explode('-',$_COOKIE['id']); |
if (md5($secret_word.$cookie_id) == $cookie_hash) { |
$id = $cookie_id; |
} else { |
die('Invalid cookie !'); |
} |
<asp 예제> |
<!--#include virtual="/crypto/MD5.asp"--> |
secret_word = “lgcard_secret_value” |
// 쿠키설정하기 |
id = “lgcard” |
hash = md5(secret_word & id); |
Response.Cookie(“id”) = id |
Response.Cookie(“id_hash”) = hash |
// 받은쿠키가변조되었는지확인하기 |
cookie_id = Request.Cookie(“id”) |
cookie_hash = Request.Cookie(“id_hash”) |
If md5(secret_word & cookie_id) = cookie_hash) Then |
‘Cookie 값이변조되지않았으므로, 세션ID 값설정 |
id = cookie_id |
Else |
‘Cookie 값이 변조되었기 때문에, 오류처리 |
End |
<jsp예제> |
String secret_word = “lgcard_secret_value”; |
// 쿠키설정하기 |
String id = “lgcard”; |
String id_hash = CryptoUtil.md5(secret_word + id); |
Cookie userCookie= new Cookie(“id”, id + “-”+ id_hash); |
Response.addCookie(userCookie); |
// 받은쿠키가변조되었는지확인하기 |
Cookie[] cookies = request.getCookies(); |
for(inti=0; i<cookies.length; i++) { |
Cookie thisCookie= cookies[i]; |
if (thisCookie.getName().equals(“id”)) { |
String cookie_value = thisCookie.getValue(); |
StringTokenizerst= new StringTokenzier(cookie_value, “-”); |
String cookie_id = st.nextToken(); |
String cookie_hash = st.nextToken(); |
if (CryptoUtil.md5(secret_word + cookie_id).equals(cookie_hash)) { |
id = cookie_id; |
} else { |
// Cookie 값이 변조되었기 때문에, 오류처리 |
} |
} |
//다른쿠키에대한처리루틴 |
} |
* 쿠키에대한 Hash 값을만들때, 공격자가 해당Hash 값을 불법으로 생성하는것을 막기위해서, 웹 사용자에게 공개 되지않는 |
secret_word 값을함께 사용한다. 이값은 해당웹어플리케이션에서 사용할수있도록 공용 설정파일등에 저장해서 사용하는것을 권장한다. |
Guide 2. 접근제어가 필요한 모든 페이지에 로그인 체크 및 권한 체크를 구현하자. |
■접근제어가 필요한 페이지 및 모듈들에는 모두 통제수단(로그인체크, 권한체크)이 적용되어야 한다. |
특히, 하나의 프로세스가 여러 개의 페이지 또는 모듈로 이뤄져 있을때 권한 체크가 누락 되었을 경우, 설정된 접근권한을 우회해서 |
트랜젝션을 실행할 수 있는 위험이 존재한다. |
■점검방법: 소스리뷰 |
■조치방법 |
1) 접근권한이 필요한 모든페이지/모듈에 해당루틴 구현 |
2) 이를위해서 공통 모듈을 사용하는 것을 권장한다. |
Guide 3. 첨부파일 업로드 기능을 통한 스크립트 업로드 및 실행을 금지하자. |
■ 게시판 첨부파일 업로드, 사진 업로드 모듈등 사용자가 임의의 파일을 서버로 전송할 수 있는 기능을 이용해서 공격자가 작성한 |
악의적인스크립트를 서버에 업로드한후, 이를 실행시킬 수 있다면 해당 서버에서 임의의 명령어실행, Web DB 불법접근및 |
해당 Application Server와 신뢰관계를 맺고있는 서버들(예, Web DB서버, 내부 연동서버등)을 공격할 수 있는 위험이 있다. |
본 취약점은 게시판 업로드 모듈뿐아니라 그림 파일을 올리는 기능을 통해서도 발견되고 있기때문에, 사용자가 파일을 업로드할 |
수 있는 모든 모듈에 적용된다. |
■점검방법 : 해당Application Server가 지원하는 Script 파일을 업로드한 후, 이를 웹브라우저로 직접 접근해서 실행이 되는지 |
확인한다. |
■조치방법 |
1) 해당 Application Server에서Script로 실행될 수 있는 확장자(예, .jsp, .asp, .php, .inc 등)로된 파일의 업로드를 차단한다. |
2) 첨부파일을 웹디렉터리가 아닌 곳에 저장한후, 다운로드 스크립트를 사용해서 사용자에게 전달할 수 있게한다. |
3) 다운로드 스크립트를 구성할때, 파일명을 Parameter로 받는것보다 파일이름은 DB에 저장하고 해당index만을 Parameter로 |
받아서 사용하면 더 안전하다. |
※주의사항 |
1) 확장자를 비교할경우, 대소문자를 무시한 문자열비교를 해야만한다. 이를 적용하지않으면 공격자는 |
“malcious.Jsp ”, “malicious.jSp ”, “malicious.jsP ” 등과 같은 파일명을 사용해서 통제루틴을 우회할 수 있기 때문이다. |
2) 웹어플리케이션 서버에서 실행 스크립트로 설정한 모든 확장자에 대해서 점검해야하며, 이들 확장자 목록은 웹 서버 관리자에게 |
문의해서 확인해야 한다. |
Guide 4. 첨부파일 다운로드스크립트를 악용한 서버파일유출을 방지하자. |
■첨부파일 다운로드 스크립트에 파일 경로를 포함한 parameter를 사용할 경우, 원하는 디렉터리를 벋어나서 임의의 파일을 다운로드 |
할수 있는 취약점이 있다. 이로 인하여 공격자는서버의 중요파일 또는 웹어플리케이션 소스파일등에 접근이 가능하다. |
■점검방법: http://localhost/download.jsp ? file=lgsec.txt와같이 구현되어있는 웹 어플리케이션이 있다고하자. |
1) Application Server가Unix/Linux인경우 |
http://localhost/download.jsp ? file=../../../../../../../etc/passwd를 입력했을때 Application Server의 /etc/passwd 파일을 |
획득할 수 없어야 한다. |
2) Application Server가 Windows 계열인 경우 |
http://localhost/download.asp ? file=../../../winnt/win.ini를 입력했을때 win.ini 파일을 획득할 수 없어야 한다. |
■조치방법 : 사용자로 부터 전송받은 디렉터리이름, 파일이름값에 “../ ” 또는 “..\ ”이 존재하면 오류처리 한다. |
Guide 5. SQL Injection 공격에 대비하자. |
■사용자로 부터 입력 받은값을 DB query에 사용할 경우, 공격자는 원하는query 문을 injection할 수 있는 취약점이 있다. |
로그인 모듈이 SQL Injection에 취약할 경우, 사용자의 비밀번호를 몰라도 정상적으로 로그인할 수 있는 위험이 있으며, 게시판 등의 |
모듈이 취약할 경우 DB 내용이 외부로 유출 또는 임의의 DB Query가 실행될 수 있다. |
■원리 |
ID, PASSWORD를 받아서 로그인 성공 여부를 처리하는 예를 들어보자. |
id = request(“id”); |
passwd= request(“passwd”); |
query = “select * from MEMBER where id = ‘” + id + “’ and passwd= ‘” + passwd+ “’”; |
로 되어있어서 결과Record가 있을 경우 회원 로그인 성공처리하는 경우, Id에 ‘ or 1=1 –- 입력할 경우 비밀번호에 상관없이 |
다음과 같은query가 만들어진다. (여기서passwd가123으로 입력되었다고 하자) |
Select * from MEMBER where id = ‘ ’ or 1=1 –-‘ and passwd= ‘123 ’ |
Oracle DB에서 –- 부분은 주석으로 처리되기 때문에 위 쿼리의 결과는 항상 첫 번째 레코드가 반환되며, 단순하게 레코드 반환 여부만을 |
점검 하는식으로 인증이 구현되어 있다면, 로그인이 성공적으로 처리되게 된다. 이를 응용하면 원하는 사용자ID로 로그인이 가능할 수 |
도 있다. |
또한 이와같은 원리를 사용해서 사용자 입력값의 조작으로 임의의 DB Query를 실행시킬 수 있는 위험이 존재한다. |
■점검방법: |
1) 검색어 필드 및 로그인ID, PASSWD 필드에 큰따옴표(“), 작은따옴표( ‘), 세미콜론(;) 등을 입력한후, DB error가 일어나는지 |
확인하자. |
2) 로그인모듈점검 |
A. MS SQL인 경우: ID 필드에[ ‘ or 1=1 ;--], 비밀번호필드에는 아무값이나 입력한 후 로그인을 시도한다. |
B. Oracle인 경우: ID 필드에[ ‘ or 1=1 --], 비밀번호 필드에는 아무값이나 입력한 후 로그인을 시도한다. |
C. 기타: ID 필드에[‘ or ‘’=‘], 비밀번호필드에[‘ or ‘’=‘]을 입력한후 로그인을 시도한다. |
* 위예제이외에도다양한방법이가능하기때문에, 로그인및사용자입력값을사용하는소스에서DB Query 생성방식을직접 |
점검해야한다. |
■조치방법 |
1) 사용자로부터 입력 받은값에 큰따옴표(“), 작은따옴표( ‘), 세미콜론(;) 문자가있으면 이를제거 또는 사용하는 DB에 맞게 변환 |
한후, DB query문장에 사용하도록한다. |
Guide 6. Cross-Site Scripting 공격에대비하자. |
■사용자가 입력한 내용을 기반으로 페이지를 동적으로 생성하는 웹어플리케이션을 악용하면, 해당페이지를 보는 사용자의 |
웹브라우저에서 임의의코드를 실행할 수 있다. 이는 로그인세션 hijacking, 악성 프로그램설치등의 client hacking이 가능하다. |
■점검방법: 게시판의제목, 내용 필드등에 <script>alert( “XSS 취약함 ”);</script> 입력한후, 내용을조회했을때, 해당스크립트가 |
실행되면 취약하다. |
■점검방법: 게시판의 제목, 내용 필드등에 <script>alert( “XSS 취약함 ”);</script> 입력한 후, 내용을 조회했을때, 해당스크립트가 |
실행되면 취약하다. |
■조치방법: 사용자로부터 입력받은 내용을 기반으로 페이지를 생성할경우, “<“, “> ”는각각“< ”, “> ”로 변경한 후 생성한다. |
1) PHP의경우, htmlspecialchars() 함수를 사용해서입력받은값을변환할수있다. |
2) Java 1.4 API 이상 |
content = content.replaceAll("<", “<"); // 사용자가입력한내용이content 변수(String 객체)에저장되어있다고가정 |
content = content.replaceAll(">", “>"); |
3) Java 1.3 API 이하 |
intlocation; |
do { |
location = content.indexOf('<'); |
if (location > 0) content = content.substring(0, location) + “<" + content.substring(location+ 1); |
location = content.indexOf('>'); |
if (location > 0) content = content.substring(0, location) + “>" + content.substring(location+ 1); |
} while(content.indexOf('<') != -1 || content.indexOf('>') != -1); |
* 주의사항 만약 HTML Tag의 입력을 허용하는 모듈일경우, 위의변환규칙대신<script, </script>, <iframe>을 각각<!--script, </script--!>, <! —iframe> |
으로 변경하며, 이때 대소문자를 무시한 패턴매칭 (Java의경우String 클래스의toLowerCase() 및 substring() 사용)을 적용해야만 한다. |
Guide 7. 사용자에게 전달된값(HIDDEN form 필드, parameter)을 재사용할경우 신뢰해서는 안된다. |
■주로 회원정보변경 모듈에 사용자의 key값(예, id)를 hidden form 필드로 전송한 후, 이를 다시받아서 update에 사용하는 경우가 |
있는데, 공격자가 이값을 변경할경우 다른 사용자의 정보를 변경할 수 있는 취약점이 존재한다. |
■점검방법: HTML 소스에서 FORM 필드 확인 후, 해당값이 어떻게 사용되는지를 소스에서 확인해야 한다. |
■조치방법: 해당값의 무결성을 검사 할수있는루틴(예, 해쉬값비교) 추가 또는 서버세션을 사용한다.` |
Guide 8. 최종 통제메커니즘은 반드시 서버에서 수행 되어야한다. (Client-Site Security is NOT secure!!) |
■JavaScript, VBScript 등을 사용한 사용자 입력값 점검루틴은 우회될 수 있기때문에, 서버에서 최종 점검하는것이 필요하다. |
물론 서버의 부하를 줄이기위해서 1차적으로 클라이언트 레벨에서 점검할 수 있으나, 보안 통제수단으로 사용할 수 없다. |
첨부파일 업로드 기능에 스크립트 파일의 전송제한하기 위해서 파일확장자검사를 script를 사용해서 웹브라우저 레벨에서 |
수행할 경우, 공격자는 해당script를 우회해서 서버에 원하는 스크립트파일을 전송할 수 있다. |
■점검방법: HTML 및 웹어플리케이션 소스리뷰 |
Guide 9. 클라이언트에게 중요정보를 전달하지말자. |
■Java Applet, ActiveX를 사용해서 C/S 어플리케이션을 작성하는경우, 클라이언트에서 실행되는 컴포넌트에 중요정보를 하드코딩 |
해서는 안된다. Cookie에중요정보를 전달할경우, 암호화를 사용해야 한다. |
■점검방법 |
1) HTML 소스리뷰 |
2) URL 주소에javascript:document.cookie; 입력해서 쿠키내용 확인 |
Guide 10. 중요정보전송시POST method 및 SSL을 적용해야한다. |
■사용자로부터 중요정보를 받을때는 POST method를 사용해야하며, 그 중요도에 따라 SSL을 사용한 암호화통신을 적용해야한다. |
SSL은 자료전송시 암호화를 지원하므로, 민감한정보는 어플리케이션 레벨의 암호화를 고려해야한다. |
■점검방법: 중요정보전달 FORM ACTION에 사용된 프로토콜이 “HTTPS”, Xecure로 되어있는지 확인함 |
Guide 11. 중요한 트렌젝션이 일어나는 프로세스에 사용자의 비밀번호를 재확인 하도록 하자. |
■사용자의개인정보변경프로세스에비밀번호를재확인하는루틴을추가할경우불법적인위장으로인한추가피해를줄일수있다. |
■점검방법: 해당프로세스확인 |
Guide 12. 중요정보를 보여주는 페이지는 캐쉬를 못하게 설정하자. |
■중요정보를 보여주는 화면에 no-cache 설정을 하지않을경우, 로그아웃을한 이후에도 [뒤로가기] 버튼을 사용해서 해당내용을 |
볼 수 있는 위험이 존재한다. |
■점검방법: 중요 정보페이지를 열어본 후, 로그아웃을 한다. 웹브라우저의 “뒤로”버튼을 눌렀을때 이전내용이 보이는지 확인. |
■조치방법: no-cache 설정을위해서HTML HEAD 부분에 아래내용을 추가한다. |
<meta HTTP-EQUIV=“Pragma”CONTENT=“no-cache”> |
Guide 13. 암호화를 올바르게 이해하고 사용하자. |
■자체개발한 암호화 알고리즘 사용을지양하며, 공인된 암호화알고리즘(3DES, SEED, AES 등)을 사용하는것을 고려한다. |
암호화키를 사용하지 않는 알고리즘은 암호화알고리즘이 아니라, 단순인코딩 알고리즘으로 기밀성을 보장할 수 없다. |
암호화키는 소스에 hard-coding되어서는 안되며, 제한된 사람만이 접근이 가능하도록 해야한다. |
Guide 14. 관리자 페이지는 내부에서만 접근이 가능하도록 하자. |
■웹 사이트관리자를 위한 페이지가 존재할경우, 외부에서 접근이불필요하다면 내부특정IP에서만 접근할 수 있도록 통제해야한다. |
■이를위해서 특정Directory에 관리자페이지들을 구성하고, 해당Directory에 접근제한을 적용한다. |
■조치방법: Apache Web Server를 사용하는경우 httpd.conf에 아래내용을추가하면된다. |
(관리자페이지가/lgsec/admin 아래저장되어있고, 관리자IP가192.168.0.101 인경우) |
<Directory “/lgsec/admin”> |
Deny from all |
Allow from 192.168.0.101 |
</Directory> |
Guide 15. 각언어에서 제공하는 보안수단을 이해한후 사용한다. |
■Java |
1) Java Class 역컴파일문제 |
Java 언어의Byte-code 특성으로 인하여Java class는 쉽게역컴파일이가능하다. 만약Java Applet에 중요정보(예, 원격지접속 |
을 위한ID/PASSWORD, DB Query, 직접제작한 암호화알고리즘, 프로그램로직 등) 를hard-coding 했다면, 이를 발견한공격자 |
는 해당정보를 악용할 수 있는위험이 존재한다. 따라서 외부로 전송되는 Java class 파일에는 중요정보를 hard-coding하는것을 |
지양해야 한다. |
2) Secure Code guidelines (Sun Microsystems) -http://www.java.sun.com/security/seccodeguide.html |
Sun Microsystems에서는Java 프로그램 개발시고려해야할 다양한 보안사항을 제공하고있다. |
■ASP(Visual Basic, C++, C# 등을사용한모든ASP에적용) |
1) include 파일을보호하자 |
2) Server.HTMLEncode |
-용도: 특정문자열에 대한 HTML encoding을 수행한다. 사용자가 입력한값으로 HTML 페이지를 구성하기전에 사용하면 |
Cross-Site Scripting 공격등에 효과적이다. |
-적용가능한IIS : IIS 5.0 이상 |
-사용법 |
<%= Server.HTMLEncode(“<script>alert(document.cookie);</script>”) %> |
-결과 |
<script>alert(document.cookie); </script> |
3) Server.URLEncode |
4) Session.Abandon |
-용도: Session 객체에 저장되어 있는 모든 정보를 삭제한다. 사용자 로그아웃 프로세스에 사용해서 기존세션정보를 |
보호하기위해서 사용할 수 있다. |
-적용가능한IIS : IIS 5.0 이상 |
-사용법 |
<% Session.Abandon %> |
■PHP |
1) [PHP 4 이상] 환경설정(php.ini) 내용중register_global을 “on”으로 설정할 경우, PHP 스크립트의 변수값을 임의로 변경할 수 |
있는 취약성이 있다. 따라서 register_global은“off”로 설정한 후, $_GET, $_POST 문을 사용해서 사용자가 전달한값을 얻어야 |
한다. |
register_global = off |
2) PHP 스크립트오류를 사용자에게 보내지 않기 위해서 PHP 환경설정파일(php.ini)에서 아래와 같이설정한다. |
log_errors = On |
display_errors = Off |
3) utf8_decode() |
-용도: UTF-8 형식의입력값을ISO-8859-1 형식으로전환해준다. 필터링규칙을적용하기전에사용할것을권장한다. |
-적용가능한PHP : PHP 3.0.6 이상 |
4) strip_tags() |
-용도: 문자열로부터HTML 테그와PHP 테그를없앤다. 사용자가입력한값을HTML 화면에출력할경우사용해서 |
Cross-Site Scripting 공격을 대비할 수 있다. |
-적용가능한PHP : PHP 3.0.8 이상 |
-사용법 |
A. strip_tags(‘<script>’); : 모든HTLL, PHP 테그를제거한다. |
B. strip_tags(‘<script>’, ‘<script><iframe>’) : 첫번째인자로전달된문자열에서두번째인자로지정된테그를제거한다. |
5) htmlspecialchars() |
-용도: 특정문자열에 대한 HTML encoding을 수행한다. 사용자가 입력한값으로 HTML 페이지를 구성하기전에 사용하면 |
Cross-Site Scripting 공격대비를위해서사용할수있다. |
-적용가능한PHP : PHP 3 이상 |
-사용법 |
htmlspecialchars(“<a href=‘test’>Test</a>”) |
-결과 |
<ahref=‘test’>Test</a> |
6) addslashes() |
-용도: DB Query와같이인용된부분앞에역슬래쉬를붙여서반환한다. 해당문자에는작은따옴표, 큰따옴표, 역슬래쉬, |
NULL 이있다. SQL Injection 공격을위해서사용한다. |
-적용가능한PHP : PHP 3 이상 |
7) include 파일을보호하자. |
8) session_destroy |
-용도: Session 객체에 저장되어있는 모든정보를 삭제한다. 사용자 로그아웃프로세스에 사용해서 기존세션정보를 |
보호하기 위해서 사용할 수 있다. |
-적용가능한PHP : PHP 4 이상 |
Guide 16. 슈퍼 유저 계정을 사용한 코딩 금지 |
반드시 필요한 경우가 아니면 관리자 및 슈퍼 유저 계정을 사용하여 코딩을 하여서는 안 되며 개발 초기 단계에서 개발하고자 하는 어플리케이션에 특화된 계정을 사용하여 개발하여야 한다. 예를 들어 SQL 서버에 접속하는 어플리케이션일 경우 ‘sa’ 계정보다는 새로운 사용자 계정을 생성하여 개발하여야 한다. |
Guide 17. 버퍼 오버플로우 |
대부분의 보안 취약점은 버퍼오버플로우 문제로 인해 발생한다. 버퍼오버플로우는 고정된 길이의 버퍼에 값을 쓸 때 버퍼의 경계값을 넘어서면서 발생하게 되는데 사용자 입력 값을 읽을 때나 프로그램 내에서 처리하는 중간에 발생한다. C언어와 C++언어는 버퍼오버플로우에 대한 보호기능을 제공하지 않으므로 CGI 프로그램을 작성할 때 아래의 사항들을 준수하여야 한다. |
- strcpy(), strcat(), sprintf(), vsprintf(), gets()와 같은 함수는 경계값을 체크하지 않으므로 strncpy(), strncat(), snprintf(), fget()과 같은 함수로 대체하여야 한다. |
- realpath(), getopt(), getpass(), streadd()와 같은 함수의 사용은 자제하고 최소한의 PATH_MAX 바이트 길이를 정해주는 getwd() 함수를 사용하도록 한다. |
- scanf(), sscanf(), fscanf() 함수 사용시에는 읽어들일 수 있는 최고의 버퍼 길이를 명시해야 한다. |
¤ 취약한 사용 예 |
char buffer[256]; |
int num; |
num = fscanf( stdio, “%s”, buffer ); |
¤ 안전한 사용 예 |
char buffer[256]; |
int num; |
num = fscanf( stdio, “%255s”, buffer ); |
- memcpy() 함수를 사용할 경우에는 복사할 대상의 크기를 체크하여야 한다. |
¤ 취약한 사용 예 |
unsigned long copyaddress( struct hosten *hp ) |
{ |
unsigned long address; |
memcpy( &address, hp->h_addr_list[0], hp->h_length ); |
} |
¤ 안전한 사용 예 |
unsigned long copyaddress( struct hosten *hp ) |
{ |
unsigned long address; |
if ( hp->h_length > sizeof( address ) ) |
return 0; |
memcpy( &address, hp->h_addr_list[0], hp->h_length ); |
return address; |
} |