Coding Convention은???


코딩가이드인데, 

본인도 본인이지만 협업을 하거나 전체전인 코드 작성법을 통일하여 

가독성을 위한 방법이며 지켜야할 규칙이다.

들여쓰기, 문법표기, 변수/함수명 정의 방법 등을 적용하는것을 말한다.


1. camelCase (카멜케이스)

단어의 조합시 첫글자는 소문자, 나머지 단어의 첫글자는 대문자로 하는 방법

ex) playToki, runToki


2. PascalCase (파스칼케이스)

단어의 조합시 모든단어의 첫글자를 대문자로 하는 방법. Java의 Class명 작성시 사용

ex) PlayToki, RunToki, YouAndMe


3. UPPERCASE

모든 글자를 대문자로 표기, 상수 혹은 중요한 식별자(identifier)를 나타낼때

ex) CONST, INTEGER, System.IO


4. snake_case

단어간의 구분을 언더바로 구분

ex) play_toki, run_toki


5. Hungarian Case

구조적인 프로그래밍 방식에서 사용되었고 변수의 type을 쉽게 구분하기 위한 방법

ex) g_intPlay(전역),  intNumber(int 타입),  strToki(문자타입)





Posted by 토끼구이 달팽이맛나

[aptana] 설정

Web Dev 2014.01.10 17:28



확장자 추가

Perferences > General > Content Types > Add



테마 변경

Perferences > Aptana Studio> Theme > 변경



jQuery 자동완성 쓰기

메뉴 > Commands > Bundle developer > install bundle > jquery 선택



폰트

Verdana 

Posted by 토끼구이 달팽이맛나

100 : Continue
101 : Switching protocols
200 : OK, 에러없이 전송 성공
201 : Created, POST 명령 실행 및 성공
202 : Accepted, 서버가 클라이언트 명령을 받음
203 : Non-authoritative information, 서버가 클라이언트 요구 중 일부만 전송
204 : No content, 클라언트 요구을 처리했으나 전송할 데이터가 없음
205 : Reset content
206 : Partial content
300 : Multiple choices, 최근에 옮겨진 데이터를 요청
301 : Moved permanently, 요구한 데이터를 변경된 임시 URL에서 찾았음
302 : Moved temporarily, 요구한 데이터가 변경된 URL에 있음을 명시
303 : See other, 요구한 데이터를 변경하지 않았기 때문에 문제가 있음
304 : Not modified
305 : Use proxy
400 : Bad request, 클라이언트의 잘못된 요청으로 처리할 수 없음
401 : Unauthorized, 클라이언트의 인증 실패
402 : Payment required, 예약됨
403 : Forbidden, 접근이 거부된 문서를 요청함
404 : Not found, 문서를 찾을 수 없음
405 : Method not allowed, 리소스를 허용안함
406 : Not acceptable, 허용할 수 없음
407 : Proxy authentication required, 프록시 인증 필요
408 : Request timeout, 요청시간이 지남
409 : Conflict
410 : Gone, 영구적으로 사용할 수 없음
411 : Length required
412 : Precondition failed, 전체조건 실패
413 : Request entity too large,
414 : Request-URI too long, URL이 너무 김
415 : Unsupported media type
500 : Internal server error, 내부서버 오류(잘못된 스크립트 실행시)
501 : Not implemented, 클라이언트에서 서버가 수행할 수 없는 행동을 요구함
502 : Bad gateway, 서버의 과부하 상태
503 : Service unavailable, 외부 서비스가 죽었거나 현재 멈춤 상태
504 : Gateway timeout
Posted by 토끼구이 달팽이맛나

Yahoo 에서 웹 서비스 속도향상(혹은 개선..)을 위한 ‘습관들(?)’ 을 새로이 올려놨음에
이에 여지없이 펌질을..

그다지 큰 규모의 웹 서비스..가 아닌 사이트에서는 (개인 홈페이지 ,묻혀진 중소 업체들의 페이지..혹은 존재감 없는 개인 만의 은밀한 사이트..) 에서는 그다지 표가 나지 않을 수도 있다.
…..고 하겠지만 전혀 아니다.

단지 그 차이점에서 오는 손익의 차이 정도가 있을 뿐이다.

슬라이드에서 나왔던 예시중에
Google 과 Amazon 가 나온다..
 - 500ms 정도 느려지면 Google 에선 평균 트래픽 발생량이 20% 가 감소한다.
 - 100ms 정도 느려지면 Amazon 에서 판매량이 1% 감소된다..

2008년 01월 google 사의 방문수는 총 1.34억 회… ( 자료 : comScore Media Metrix 2008. 01 (미국내 기준..))
Amazon.com 의 2007년 4분기 매출액은 56.7억불 ( 자료 : Yahoo Finance )

저것을 기준으로 한다면
Google 은 월 평균 2700만명 의 방문자를 놓치게 되며..
Amazon 은 매 분기별 5600만불에 달하는 손해를 입게 된다..

기준점이 될런지 모르겠지만 대략 저들에게 있어서 0.1초의 중요함을 대신 느껴보는게 어떠한가.

당신의 웹 사이트 속도를 향상 시키기 위해서 과연 무엇을 해야 할 것인가.
Yahoo에서 이전에도 이와 비슷한 PT 를 발표한적이 있다.
(Firefox Add-on 인 YSlow 를 설치해도 볼 수 있는..)

거기서 다루는 14개의 조건 들 이외에 추가로 20여개의 주제를 다룬다.

1.  HTTP 요청횟수를 최소화 하라.. (Make fewer HTTP requests)
 요청하는 요소들 (Components) 를 최소화 하는것이 빠른 페이지 로딩에 도움이 된다.
 이는 다수의 HTTP 요청에 의한 오버헤드(overhead) 를 줄여주기 때문이다.
 이를 위해선 CSS/Javascript 등을 통합하여 사용 하거나 이미지는 CSS 스프라이트(Sprites) 를 이용하는게 좋다.

CSS 스프라이트 (CSS sprites) 라는 것은 예전에 게임 등에서 도 이용했던 방법인데
하나의 이미지를 로딩하여 해당 이미지의 일정 부분 만 출력하되 롤오버나 이미지 변환등을
구현할때 해당 이미지의 background-position 을 이동하면서 비슷한 효과를 내는걸 말한다.

2. CDN(Contents Delivery Network) 을 이용하라 ( Use a Contents Delivery Network)
 정적 요소( 이미지나 js 등 특별히 변화되는 파일이 아닌 모든것들..) 을 최종 사용자에게 빠르게 전달하기 위해서 사용자의 네트웍과 가장 근접한 네트웍에서 해당 컨텐츠를 전달하는 것이다….

하지만 실질적으로 이정도 규모를 제공할려면 역시 돈이 좀.;;

3. 캐쉬 제어 . ( Add Expires header or Cache-Control )
 일반적인 정적요소들 ( 이미지,js , css 혹은 내용이 변화 될리 없는 정적 문서 및 파일…) 은
캐쉬 유지시간을 아주 길게 잡아주거나 혹은 계속 캐쉬 하게 함으로써 . 브라우저에서 다시
해당 파일을 서버에 요청하지 않도록 한다. 물론 변경을 해야 할때는 해당 파일명을 바꾼다던지 해서 새로이 캐쉬를 하면 된다..

 동적으로 변화 되는 부분에 대해서는 정책에 따라 캐쉬를 제어 하는데.
 헤더 (Header) 의 Cache-Control 을 이용하거나 혹은 브라우저에서 If-Modified-Since 헤더(Header) 를 이용하여 갱신을 하도록 한다.

 한마디로 동적 컨텐츠에 대해선 일정한 정책(policy) 을 세워 가급적 캐쉬 이용을 유도하는
방향으로 처리하는게 좋다는것이다.

4. 압축하라!! ( Gzip Components )
서버에서 압축해서 보내면 브라우저에서 알아서 압축을 풀게 된다.
요즘 사용하는 모든 브라우저는 기본적으로 제공하니 크게 문제 될리는 없을것이다.
(설마 아직도 IE3.01 이런걸 쓰는 사람들이??..)
가급적 모든 요소들( Components ) 을 압축전송을 하는게 좋다.

하지만 -_- 첨부 파일 다운로드 등을 시도할때
gzip 으로 압축해서 보내는 경우 문제가 생기기도 하는데 이럴땐 적절히 대응하는 것이 좋을듯.

5. CSS 선언은 맨 위에! ( CSS at the Top )
 FireFox 나 IE 는 CSS 파일이 로딩 될때까지 어떠한 내용도 랜더링 하지 않는다.
심지어 인쇄를 할때도 말이다. 그러니 가급적이면 Style 선언부를 맨 위에 올려 놓는게 좋다.

기억하라 일단 눈에 뭔가를 보여줘야 사용자들은 인내심을 가질 수 있다.

6. Javascript 는 맨 나중에. ( Move Script to the Bottom )
=> defer=”defer” 옵션을 주면 위에 기재를 하더라도 맨마지막 실행
 Javascript 도 CSS 와 유사한 문제를 발생시키는데 이를 해결방안은 다르다. CSS 에서는 해당 StyleSheet 가 로딩될 때 까지 페이지 랜더링을 하지 않는데. Javascript 는 해당 스크립트를 로딩하는 동안 그 아래에 있는 모든 컨텐츠 요소들을 랜더링하지 않게 된다. 만약 해당 스크립트 처리에 시간이 오래 걸린다면 결국 전체 페이지 출력 시간에 문제가 될 수 있는 부분이다.

또 하나의 문제는 바로 HTTP 의 다중 연결(parallel downloads) 에 관한 문제다.
HTTP 1.1 규약에서는 호스트당 최대 2개 이상의 연결은 할 수 없다. 다만 다수의 호스트에 연결하여 2*n 개의 요소들(Components) 을 받아 올 수 있다( IE 에서는 100개 이상의 이미지를 한번에 로딩이 가능하다 한다..) 하지만 스크립트 파일을 로딩중엔 이것이 불가능하게 된다는 것이다. 결국 페이지 출력시간은 그만큼 딜레이가 된다는 것.!

(이부분에 대한 이해가 좀 딸리는데 영어빨도 안되다 보니 애먹은 부분이라 원문을 따로 링크를 붙여 놓습니다 . Yahoo Developer - Put JS at the bottom )

7. CSS Expression() 표현식은 가급적 자제해라. ( Avoid CSS Expressions )
 마땅히 해석할만한 말이 없어서 ‘표현식’ 이라고 했는데.
내용은 간단하다. CSS 내에서 IE 5 부터 시작된 강력한 기능이라는데. 이건 IE 에서만 되는 기능에다가 또한 많은 연산을 발생시킨다.

한마디로 -_- 써봤자 좋을것 없는 짓이라는 결론..!

8. CSS 와 JS 를 HTML 에서 분리해라! ( Make Javascript And CSS externel )
 분리 해 놓으면 캐쉬정책에 따라 따로 로딩할 필요가 없게 되고 다른 페이지에서도 공통으로 이용 가능할 수도 있게 된다. 물론 좀더 많은 HTTP 연결을 요구하게 되겠지만 만약 이것이 HTML 페이지에 있었다면 그만큼 증가한 파일 사이즈 만큼 매번 로딩하게 될 것이다.
무엇이 유리할지는 당신이 판단하면 좋을듯~ ^^

9. DNS 에 질의를 줄여라! ( Reduce DNS lookups )
 DNS 가 어떤 역할을 하는지는 다 알것이다. 도메인 명 을 IP 주소로 변환해주는 역활을 하게 되는데 이것 또한 바로바로 되는것은 아니다. 보통 20~120ms (밀리세컨드) 정도 소요되는데 그동안 브라우져는 주소를 받을때 까진 조용히 손가락만 빨고 기다려야 한다는 것이다.

만약 DNS 정보를 Cache 해 놓는다면 좀 났겠지만 그 역시 ip 가 변동된다면 문제가 될것이다.

그렇지 못하다면 도메인 수 만큼 DNS 에 질의를 던져야 할것이고 그만큼 딜레이가 걸린다고 봐야한다. 하지만 도메인 수가 늘어나게 되면 병렬 처리수도 증가 한다는 이야기므로 적정선을 찾아본다면 좋을것이다. 슬라이드에서는 한페이지당 2~4개 정도의 도메인이 적절하다고 한다.

10. Javascript 의 다이어트! ( Minify JavaScript )
 무슨이야긴고 하니! Javascript 내에 불필요한 부분들은 모두 삭제를 한다는 것이다.
예를 들자면 주석나 긴 변수명을 짧게 한다던지 중간에 공백 문자열을 지운다던지 해서 말 그대로 전체 코드 사이즈를 줄인다는 것이다.

사실 주석 같은거야 인간이 보기 위해서 존재할뿐 컴퓨터에겐 전혀 의미가 없다.
장문의 주석은 컴퓨터에겐 쓸데없는 부분일 뿐이다. 하지만
하지만 코딩하는것은 어디까지나 인간 ! 그렇게 변환된 코드는 디버깅하는데 난해함을 줄 수 있다 .

그렇게 된 소스를 디버깅하는것은
인간의 인내심과 엄청난 시력! 그리고 손가락이 고생하게 된다…ㅡㅡ;;;

슬라이드에는 Dojo Compressor (ShrinkSafe), YUI compressor 나 JSMin 을 소개하고 있는데 Dojo Compressor 같은 경우엔 어느정도 가독성을 보장한 형태로 코드를 다이어트 시켜주므로 한번쯤 써볼만 툴인거 같다.

11. 페이지 리다이렉트 연결은 가급적 자제 .( Avoid Redirect )
 HTTP 연결을 시도하지만 바로 다른곳으로 보내게 된다. 결국 그것은 무의미한 HTTP 연결에 시간을 낭비했다고 봐야겠다. 게다가 History Back 버튼에 대한 연결 처리도 신경서야 할것이다.

자주 겪게 되는 리다이렉트 문제가 URL 끝에 디렉토리 PATH 의 슬래쉬(/) 를 빼먹어서 리다이렉트 되는 경우다 Apache 의 mod_rewrite 나 Alias 를 이용해서 처리 할 수도 있다는데.

리다이렉트 를 너무 많이 쓰다보면 개발자들이 혼란을 겪을 우려도 있고 가급적이면 지양해야하는 편이 좋다!

12. 중복된 스크립트 제거 ( Remove Duplicate Scripts )
굳이 말이 필요할까 ㅡㅡ? 말 그대로 같은 파일을 또다시 로딩할 필요는 없는데 또다시 로딩하지 않도록 제거해야 한다는 이야기다.

13. ETags 설정! ( Configure ETags )
이것은 브라우져에서 캐쉬된 파일의 갱신 여부를 확인하기 위해서 참조하는 정보이다.
이것을 참조하여 해당 파일이 변동 되었는지 체크하기 때문에 캐쉬 관리에 좀더 도움이 될것이다.

14. Ajax 도 예외는 아니다! ( Make Ajax Cacheable )
 수많은 Web 2.0  Ajax 로 구현한 어플리케이션도 위에서 말했던 요소들처럼 Gzip등을 이용해서 압축전송을 하고 캐쉬가능한 데이터는 캐쉬하도록 구현하는 것이다.!
 
Ajax 자체가 비동기식 처리 방식 덕분에 페이지 표시에 그다지 문제가 되지 않을것 같지만.
어디까지나 처리하는데 실제 보여지는 페이지에 들어나지 않지만 그것이 페이지 표시에 신속함을 말하는것은 아니다.

게다가 비동기 처리로 인하여 서버로 요청횟수가 기하 급수적으로 늘어날 수 있다.
만약 이것이 비용이 적은 연산이라면 모르겠지만 다수의 메세지를 로딩한다거나. 큰 파일을 불러온다든지의 비용이 큰 연산이라면 그것은 서버의 전체적인 속도에 영향을 미치게 된다.

이를 막기 위해서 가급적 한번 로딩된 데이터들은 캐쉬 해뒀다가 다시 서버로 요청이
가지 않도록 프로그래밍 하는것이 적절할 것이다. 이것은 빠른 응답속도와 서버 리소스의 효율적인 사용을 위해서도 꼭!! 필요한것이다.

여기 까지가 이전에 언급하였던 웹 14가지의 요건들이다.

여기까지 모두 클리어 하였다면 !!
( YSlow 에서 위 조건을 모두 충족 시켜주면 “A” 라는 평가를 받게 된다 ㅡㅡ;;..)

그 다음엔 무엇을 해야 하는가!!!

1. 서버에서는!! ( Tag : Server )
 - 버퍼를 빨리 빨리 비워라!! ( Flush the Buffer early )
   * Server-Side Script 언어들 에서는 출력을 위해서 버퍼에 처리 결과를 담게 된다.
     하지만 중간에 처리되는 부분이 오래 걸리게 되면 출력 시간에 지연이 오게 된다.
     이때 미리 처리 된 부분만큼 먼저 버퍼에 쌓인 처리 결과를 출력하는 것이다.! 그럼 보다 빠르게 출력됨을 알게 될것이고 이것은 체감상 빠르게 로딩됨을 느끼게 된다.

 - Ajax 요청은 GET 방식으로!
  * GET 방식이 데이터의 재사용하는데 좋고 POST 방식보다 전송 단계가 짧고 ( POST 방식은 헤더를 전송한뒤 데이터를 전송하게 된다 )  GET 방식의 경우엔 한 패킷에 전송이 가능하기 때문이다.
   GET 방식으로 전송되는 데이터 양에는 한계가 있지만 ( IE 경우 2KB 가 한계 ..) 굳이 POST 방식으로 보낼만큼의 데이터가 많은 경우가 흔한가??

2. 컨텐츠!! ( Tag : Content )
 - 무엇을 나중에 불러 올것인가.? ( Post-load Components )
  * 페이지의 어떤 부분이 가장 먼저 보여야 할 것인가 를 결정하는 것이다. 처음 부터 보여지지 않을 부분을 출력하기 위해서 로딩속도를 저하 시켜야 하는가? 페이지가 보여진뒤 로딩하면 그만 아닌가!! 그것을 위해서 Javascript 를 이용하는것이다! ( Rule .6 JS to the Bottom 참고 )
 
- 어떤것을 먼저 불러야 하는가! ( Preload components )
 *  위와 같은 맥락으로 사용자가 이후에 어떤 데이터를 불러 오게 될것인가. 미리 준비한다는 것이다. 분명 사용자들이 보편적으로 이용하는 패턴을 통해서 미리 사용자가 다음엔 이런것들을 찾게 되겠지 하고 미리 그 결과를 만들어 놓고 대기 하는 것이다. 그럼으로 하여 신속한 페이지 이동을 하게 될 수 있게 되는것이다.

 구글의 스프라이트 이미지 랄지 , 야후 검색에서 사용자가 다음 어떤 단어를 타이핑할 데이터를 검색 박스에 불러 온다던지 말이다.

- DOM 객체의 숫자를 줄여라! ( Reduce Number of DOM elements )
 * 이건 아주 근본적인 이야기다! 가장 빠른 로딩 시간을 보장하는것은 아무것도 띄우지 않은 화면이다. 페이지 에 객체가 늘어나고 복잡해지는 것은 그만큼 전송해야할 양이 늘어난다는 것이고 Javascript 에서 DOM 으로의 접근 속도도 느려지게 된다.
  또한 잘못된 Markup 문법 또한 문제가 된다.

- 쪼개라! ( Split components accross domain )
 * 최대한 동시 전송 가능한 갯수를 늘려라 . 하지만 너무 많이 늘려서 너무 많은 DNS질의를 보내지 않도록 한다 ( 2~4개 정도 )
 IE 8 에서는 호스트당 동시 처리 연결 갯수를 6개 로 늘린다는데..

- Iframe 을 남발하지 말라! ( Minimize the Number of IFRAMEs )
 * 광고나 다른 외부 컨텐츠를 불러오는데 유용하게 쓰일 수 있지만. 아무것도 안 부를땐 그냥 낭비일 뿐이고 페이지 로딩에 방해가 된다.

 - 못찾는 파일은 없애라! ( No 404s )
 * 404 는 Not Found 의 HTTP 오류 코드 다 ㅡㅡ;;; 보통 이렇게 못 찾는 파일이 있을 경우
  해당 파일을 호출하기 위해서 계속 로드를 하게 된다 이는 전체적인 로딩 시간을 잡아 먹게 되는데 외부 Javasript 파일을 못찾게 되면 브라우저에서는 계속 로딩할려고 시도하게 되고 결국 다른 요소(Components ) 의 로딩을 방해하게 된다.

3. Cookie ( Tag : Cookie )
 - 불 필요한 쿠키는 삭제하고, 쿠키의 크기는 가능한 최소화 한다!
  * 쿠키로 인하여 브라우져의 응답시간의 지연 현상이 일어나게 된다. 가급적이면 쿠키의 만료시간은 짧게 잡고 사용하지 않는 쿠키에 대해선 바로바로 삭제 해주는 것이 좋다.

4. 자바스크립트! ( Tag: Javascript )
 - DOM 접근을 최소화 하라!
  * DOM Access 는 상당히 느린 편이다. 가급적이면 캐쉬할 수 있도록 하며 Javascript 에 의한 수정은 삼가한다.

 - 보다 똑똑한 이벤트 관리방식을 이용하라! ( Develop Smart event handler )
  * onload 보단 DOMContentLoaded 를 써라!
  * 늘어나는 이벤트 들을 위해 attach listener 를 이용하라. ( …이부분은 좀 -_-..)
  * IE 메모리 누수 현상이 있을만한 곳은 정리!
  * onresize 시엔 조심하라!

객체 혹은 다른 요소들(Components) 에 어떠한 이벤트가 호출이 되면 다양한 메소드 들을 호출하게 된다. 또한 요소들의 숫자가 기하 급수적으로 늘게 되면 일일히 각 요소들(Components)에게 등록된 이벤트 들을 수정하기도 힘겨워 지고 코드도 보기 힘들어진다.

그러기 위해 AttachEvent 나 eventListener 같은걸 이용하는것이 적절할 수도.

5. CSS !! ( Tag : CSS )
 - StyleSheet 파일은 위에서 언급했던 것 처럼 페이지 로딩 최 상단에 배치한다.
 - 필터 사용은 자제 ( Avoid filter )
  * IE 전용에 메모리도 많이 먹고 랜더링 중에 브라우져를 멎게 할 수도 있다.
    게다가 이미지에 먹히는게 아니라 블럭 에 먹히는 거라 원하게 나오지 않을 수도 있다.
   ** IE6 에서는 문제가 되었지만 IE7+ 에서는 수정 되었다 함

6. 이미지 ( Tag : Image )
 - 필요이상의 큰 팔레트 사이즈를 갖는 GIF 이미지를 만들지 말라! 너무 많은 색을 쓰는것도 파일 사이즈를 증가 시킨다.
 - GIF 를 PNG 로 대체 하라 ..대세는 이제 PNG 다!!
 - 이미지 헤더의 주석을 삭제하라! 이로써 이미지 용량을 많이 줄일 수 있다.(생각외로 큰듯..)
 - CSS sprite 최적화!
   * 가로든 세로든 이동할 방향을 결정하고 비슷한 색을 이용하여 만든다.
     단, 너무 크게는 만들지 말라 크게 만들면 파일 사이즈의 크기도 기하 급수적으로 늘어나기 때문이다~ 그러니 되도록이면 바싹바싹 빈공간을 최소화 하는것이 좋다!
 - 이미지를 HTML 에서 크기를 조절하지 말라!
  * 원본 크기에 안 맞게 나올 수 있다.
 - favicon. 는 최대한 작고 저장 가능하게.
 

7. 이동기기 ( Tag: Mobile )
 - 모든 요소들은 가급적 25K 보다 작게 만든다!
  * iPhone 에선 그보다 크면 캐쉬 불가.
  * 압축이 풀린 상태에서 25K 가 넘어가지 않게 한다.
  * HTML 코드도 최소화!

이렇게 최적화를 하는 이유는 앞서 슬라이드에서도 밝혔지만.
Server-Side 에서 최적화를 하는데는 분명 한계가 존재하고 들인 공에 비하면 크게 티가 나지 않는 경우가 많다.

실질적으로 사용자들이 체감하는 로딩속도는 최초 클릭후 무엇인가가 출력이 되고 있구나 라는것을 봤을때 부터다.

그 단 몇초만 잡는다면 이용자들에게 보다 쾌적함을 줄 수 있는 서비스가 될것이다.

누구라도 한번 로딩에 수십초씩 걸리는 서비스를 이용하길 바라는 사람은 없을것이다.

당신이 바꾼 한줄의 코드에 사용자들이 얼마나더 쾌적함을 느낄수 있느냐 없느냐는 분명 큰 차이다. 앞으로 웹 서비스는 계속 늘어날 것이다.

물론 모두가 Google 이나 Amazon 같은 서비스가 되진 않겠지만.
많이 티가 나진 않아도 보다 적은 비용으로 당신이 만든 서비스를 더 많은 사람들이 이용 할 수 있게 된다면 그것이 중요한것 아닐까?

참고 : Ajaxian.com - Yahoo release new performance best practices
         Yahoo Developer ( YSlow )

Posted by 토끼구이 달팽이맛나


//스크롤바의 위치값

document.body.scrollTop //위

document.body.scrollLeft //옆
Posted by 토끼구이 달팽이맛나
<-- test1.php -->
<script type="text/javascript>
  function submitFrame(f){
    f.action="test2.php";
    f.method="myiframe";
    f.submit();
  }

</script>
<form id="form"  action="test2.php" method="POST">
  <input type="text" name="data" />
  <iframe width="500" height="500" name="myiframe"></iframe>
 <input type="button" value="" onclick="submitFrame(mail)" />
</form>


<-- test2.php -->
<?
  echo $_POST['data'];
?>

Posted by 토끼구이 달팽이맛나
이미지 맵의 형태
 이미지 맵의  형태는 4가지로 나누어 집니다. 사각형(rect) , 원형(circle) , 다각형(poly), 기본형(default)으로 나누어 지는데 단순히 이미지 맵의 모양에 따라 분류된 것이지만 좌표값을 구할때는 형태마다 각각 그 좌표값을 구하는 방법이 다르답니다.

이미지 맵 태그 ( <map></map> )
 이미지 맵을 만들 때 사용하는 태그는 당근 이미지와 링크를 사용하기 때문에 이미지태그와 링크태그가 사용됩니다. 단 이미지태그(img태그)는 그대로 사용되는데...링크태그는 <a>태그가 아니라 <area>태그를 사용합니다.  일단 이미지 맵이 어떤 태그에 의해서 어떻게 만들어 지는지 그 구조를 살펴보도록 하겠습니다.^^

<img src="이미지주소" usemap="#맵이름">  ① 이미지 태그 부분. 
<map name="맵이름">  ② 이미지 맵 태그 시작부분.
<area shape="맵종류" coords="좌표값" href="링크될 주소">  ③ 맵 종류, 좌표값, 링크될 곳 설
     정 부분.
</map>  ④ 이미지 맵 태그 끝 부분.

 ① 이미지 태그 부분
 이미지 맵이 사용될 이미지가 불러주는 곳입니다. 주의 할 점은 뒤에 usemap="#맵이름" 속성을 반드시 넣어주어야 한다는 것입니다. 맵이름은 여러 분 맘대로 정해서 넣어 주시면 됩니다. 단, 맵이름은 항상 같아야 하며, 가급적이면 영문소문자로 정해주시기 바랍니다. 웹페이지 파일명 만들때도 마찬가지인데.... 한글로 해도 되긴 되는데 인터넷이란게 원래 영문권 나라에서 만들어진 것이기에 한글로 해놓으면 브라우저가 가끔식 인식을 못하는 경우가 있기 때문입니다.
 ② 이미지 맵 태그 시작부분
 본격적으로 이미지 맵 태그가 시작되는 부분입니다. 이미지 맵 태그는 <map></map> 입니다. 이 부분에서는 위에 ①부분에서 지정해주었던 맵이름을 name="맵이름" 으로 넣어 줍니다. 이건 이미지와 이미지 맵태그를 서로 연결시켜주는 역할을 하기 때문에 아주 중요합니다. 반드시 같은 맵이름을 넣어주어야 하고요... 주의할 점은 "#" 표시를 빼준다는 것입니다.
 
 다음 페이지에서 계속 설명드리도록 하겠습니다....... go! go!

Posted by 토끼구이 달팽이맛나

 

'Apache Environment를 사용할 때 발생할 수 있는 SQL Injection 취약성'에 관한 핵심 정리

 

 

by Beist Security Study Group
(http://beist.org)

Members of Beist Research Group : beist and anonymous people
Members of Beist Study Group : beist, dars21, obhacker, passion, p-jackpot, jacaranda, cina, algot23

 

 

 

 

요약: 본 문서는 [이승진, Apache Environment를 사용할 때 발생할 수 있는 SQL Injection 취약성, 2003] 문서에서 제시한 기법을 Beist Security Study Group에서 핵심 내용만 간추려 정리한 문서이다. 일반적으로 magic_quotes_gpc 설정이 on으로 되어 있는 환경에선 SQL Injection 공격을 하기가 힘들다고 생각되는데 웹 프로그램에서 Apache Environment를 잘못 사용할 경우 SQL Injection을 성공할 수 있는 가능성이 있다. 본 문서는 이러한 문제에 대해서 다루고 있다.

 

 

 

 

 

 

 

1. 개요

대부분 웹 프로그램은 해당 프로그램에서 사용하는 정보를 유연하고 편리하게 관리하기 위해 데이터베이스와 연동하여 동작한다. 데이터베이스와 연동을 하기 위해서 웹 프로그램은 Parameter를 통해 데이터베이스에 보낼 데이터를 지정한다. 이때 데이터베이스로 넘어가는 Parameter를 악의적으로 조작하여 시스템에서 부당한 정보나 권한을 획득하는 공격 기법을 SQL Injection이라 한다.

[이승진, Apache Environment를 사용할 때 발생할 수 있는 SQL Injection 취약성, 2003] 문서에서는 웹 프로그램을 작성할 때 Apache Environment를 잘못 사용할 경우 일어날 수 있는 SQL Injection 기법에 대해서 제시하였다. 내용을 간단히 살펴보면 기존 웹 프로그램을 공격할 경우 magic_quotes_gpc 의 제한 때문에 SQL Injection 공격을 수행하기 힘든 경우가 종종 있었는데 위 문서에서는 Apache Environment를 잘못 사용할 경우 이를 우회하여 공격할 수 있는 방법에 대해서 나타내었다.

본 문서는 위 문서를 바탕으로 Beist Security Study Group에서 핵심적인 내용만 간략하게 정리 요약한 문서이다. 또한 본 문서는 SQL Injection 공격 기법에 관한 기초 지식 설명은 생략하였다.. 이에 관한 지식은 인터넷에서 쉽게 문서로 접할 수 있다.

 

 

 

 

 

 

2. 기술적인 내용

먼저 magic_quotes_gpc 가 무엇인지 간략히 알아보겠다. 해당 옵션에 관련된 PHP 옵션 정보를 인용하면,

 

 

--인용--

magic_quotes_gpc boolean

GPC (Get/Post/쿠키) 작동의 magic_quotes 상태를 설정합니다. magic_quotes on이면, 모든 ' (작은 따옴표), " (큰 따옴표), \ (백슬래쉬), NUL은 자동적으로 백슬래쉬로 이스케이프됩니다.

 

참고: magic_quotes_sybase 지시어도 ON이면 magic_quotes_gpc가 완전히 교체됩니다. 두 지시어를 모두 활성화하면 작은 따음표는 ''이스케이프합니다. 큰 따옴표, 백슬래쉬, NUL은 건들이지 않고, 이스케이프 하지 않습니다.

--인용--

 

 

, 결론을 내리면 PHP 설정에서 magic_quotes_gpc on으로 되어있을 때 SQL Injection 기법을 사용하기가 좀 더 어려워진다. 왜냐하면 SQL Injection 공격의 핵심이 되는 작은 따옴표, 큰 따옴표 등이 이스케이프 처리되어 공격에 이용할 수 없기 때문이다.

본 문서는 magic_quote_gpc 옵션이 on으로 되어있을 때, 이 옵션 자체를 우회하는 방법에 대해서 설명하지 않는다. 그러나 특정 웹 프로그램의 경우 Apache Environment 변수를 직접적으로 가져와 사용하는 경우가 있는데, 이때 취약성이 발생할 수 있고, 이에 관해서 초점을 맞춘다. 다음 코드를 보자.

 

 

env_test.php

<?

 

echo "HTTP_USER_AGENT : \t\t$HTTP_USER_AGENT\n";

echo "getenv(\"HTTP_USER_AGENT\") : \t" . getenv("HTTP_USER_AGENT") . "\n";

 

?>

 

 

위의 php 코드는 env_test.php 에 접근한 사용자의 웹 브라우저 정보에 대해서 2가지 형태로 출력해준다. 첫째는 $HTTP_USER_AGENT 변수이고, 둘째는 Apache 웹 서버로부터 물려 받은 환경 변수 HTTP_USER_AGENT getenv() 함수로 가져와 출력해준다. 다음과 같은 HTTP 요청을 보내서 결과를 보겠다.

 

 

[beist@localhost beist]$ telnet beist.org 80

Trying 222.239.227.44...

Connected to beist.org (222.239.227.44).

Escape character is '^]'.

GET /env_test.php HTTP/1.1

User-Agent: test

Host: beist.org

 

HTTP/1.1 200 OK

Date: Sun, 20 Nov 2005 07:58:39 GMT

Server: Apache/2.0.50 (Fedora)

X-Powered-By: PHP/4.3.8

Content-Length: 59

Connection: close

Content-Type: text/html; charset=euc-kr

 

HTTP_USER_AGENT :               test

getenv("HTTP_USER_AGENT") :     test

 

 

User-Agent 부분에 test를 입력한 결과, env_test.php 에서 각각 동일한 결과를 출력해주었다. 다음은 User-Agent Escape 문자를 포함하여 보낸 결과이다.

 

 

[beist@localhost beist]$ telnet beist.org 80

Trying 222.239.227.44...

Connected to beist.org (222.239.227.44).

Escape character is '^]'.

GET /env_test.php HTTP/1.1

User-Agent: test'hack

Host: beist.org

 

HTTP/1.1 200 OK

Date: Sun, 20 Nov 2005 08:00:10 GMT

Server: Apache/2.0.50 (Fedora)

X-Powered-By: PHP/4.3.8

Content-Length: 70

Connection: close

Content-Type: text/html; charset=euc-kr

 

HTTP_USER_AGENT :               test\'hack

getenv("HTTP_USER_AGENT") :     test'hack

 

 

이스케이프 문자를 포함하여 보낸 결과 서로 다른 출력을 보여주는 것을 확인할 수 있다. 이러한 원인을 살펴보면, getenv()를 이용하여 가져온 환경 변수는 PHP가 아닌 웹 서버에서 저장하고 있는 환경 변수이다. , PHP에서 어떠한 처리 과정을 거치기 이전의 변수이다. 그러므로 사용자가 보낸 데이터는 순수한 형태로 웹 서버의 환경 변수에 보관되어 있다. 반면에 $HTTP_USER_AGENT PHP에서 만들어낸 것으로, 웹 서버가 갖고 있는 HTTP_USER_AGENT 변수 값을 가져와 가공한 (여기서는 이스케이프 처리를 가공 과정의 한 예라고 볼 수 있다.) 것이다.

만약 위의 사례처럼 웹 프로그램에서 getenv() 함수를 이용하여 특정 환경 변수를 가져올 경우 이스케이프 처리가 되지 않으므로 해커 입장에서는 SQL Injection 공격에 유용하게 악용할 수도 있다. 이 공격 기법은 GET이나 POST등으로 전달되는 Parameter를 조작할 순 없기 때문에 공격에 한계가 있을 수도 있다. (대부분의 Parameter GET, POST로 전달되기 때문이다.) 그러나 실제로 이를 이용한 공격 기법이 적지 않게 잠재하고 있다고 생각된다. 의외로 웹 프로그램에서 getenv() 함수를 이용하여 환경 변수를 가져오는 경우가 많이 존재하기 때문이다.

취약 잠재 가능성을 가진 환경 변수를 예를 들어 HTTP_X_FORWARDED_FOR HTTP_USER_AGENT를 볼 수 있다. 이 환경 변수는 사용자가 마음대로 조작할 수 있는 변수인데 이를 악용할 경우 SQL Injection 공격을 할 수 있는 가능성이 존재한다. 물론 이외에도 getenv()를 이용하여 가져오는 모든 환경 변수도 주목해야 한다.

 

 

 

 

 

 

3. 마치는 말

본 문서에서는 핵심 원리에 대해서만 알아보았지만 SQL Injection에 대한 지식이 있다면 이를 응용하기 어렵지 않을 것이다. SQL Injection은 아직까지도 주요 웹 해킹 기법 중에 하나로 인식될 정도로 많이 사용되기 때문에 이 부분에 대해서 각별한 주의가 필요하다. 대부분 해킹 기법의 기술적인 최종 목표는 Shell을 획득하는 것이지만 웹 해킹의 특성 상 작지만 부당한 권한으로도 웹 사이트에 치명적인 피해를 입힐 수도 있기 때문에 더욱 주의가 요구된다.

이외의 연구로, magic_quotes_gpc에서 GPC GET, POST, COOKIE를 나타내기 때문에, HEAD 등의 Method로 요청할 경우엔 이스케이프가 어떻게 처리될지 살펴보았는데 내부적으로는 같은 Method로 취급하기 때문에 다른 HTTP Method로 보내더라도 이스케이프 처리가 되므로 안심해도 된다.

(또한 앞에서 HTTP_X_FORWARDED_FOR를 예로 들었는데, 본 문서와 직접적으로 관련은 없지만 이에 대해서 한가지 더 첨부하자면, 대부분 웹 프로그램은 이 변수 값을 신뢰하는 경향이 있다. 이것은 사용자의 주소를 나타내는 값인데, REMOTE_ADDR 변수 값과는 달리 사용자가 직접적으로 조작할 수 있기 때문에 가급적이면 사용을 피하고 굳이 사용을 한다면 적절한 조치를 취한 후 사용해야 한다.)

Posted by 토끼구이 달팽이맛나