RSS구독하기:SUBSCRIBE TO RSS FEED
즐겨찾기추가:ADD FAVORITE
글쓰기:POST
관리자:ADMINISTRATOR
'프로그래밍'에 해당되는 글 5
2006/07/11  더블포인터  (3)
2006/04/17  완벽한?  
2006/04/13  PHP 보안 - 2장 : 폼과 URL  
2006/04/11  PHP 보안 - 1장  
2006/04/07  게임 만들다  (1)
소스코드


결과창



다이어그램


Quotataion
포인터 변수 앞에 쓰인 '*' 연산자는 보통 "P가 가리키고 있는 변수의 값을 가져온다" 라고 말하는데, 사실 정확한 정의는 "P가 가리키고 있는 곳=장소" 그 자체입니다.

출처 : http://blog.naver.com/bitessay/130004157487


My Comment
아니 왜 이걸 몰랐을까. Direct X를 공부하다가 뜬금없이 포인터에서 막혔다. 더블포인터의 개념에 대해 제대로 숙지하지 못해서 이런 일이 생겼다. 잘 생각해보니 "*"이라는 연산자가 무엇을 의미하는지도 제대로 모르고 있었던 것이다.

네이버 지식인에서 적절한 예제를 찾아 직접 코드를 돌려보고 그림을 그려보니 이해가 되었다. 너무 기쁜 나머지 스크린샷을 뜨고, 다이어그램을 직접 그려서 포스팅한다.

그러니까 결론은 연산자 "*"의 의미는 "포인터 변수가 가리키는 곳에 있는 값"이 되겠다.
그래서 "**"은 "포인터 변수가 가리키는 곳에 있는 값이 가리키고 있는 곳의 값"이 되겠다.

난 돌아보니 기본도 모르고 있었어. 허허허허...
그래도 기분은 좋아. 확실히 알게되었거든!


----------------------------------------------------------------------------------
추가판
더블포인터를 사용하는 이유

만약에 그냥 포인터 값을 넘겨 받는다면, 포인터가 가리키는 영역이 (null로 아직 지정이 안되있을수도 있고) 확실하지 않을수가 있으므로 그곳에다가 데이터를 쓰게 된다면 잠재적인 메모리 에러의 원인이 될 수 있다. 그러므로 더블포인터를 사용하고 함수 내부에 동적할당과정을 맡겨버리면, 함수가 메모리를 할당하고 그 주소값을 메모리를 가리키는 포인터에 초기화시키게 되고 그 포인터의 주소값을 더블포인터 변수에 넣어주는 것이 안전하기 때문이다.

그냥 포인터를 넘겨줄수도 있겠지만 좀 더 안전한 처리를 하기 위한 함수 디자인상의 이슈라고 할 수 있겠다.

두서없지만 내가 이해한대로 적어본다.
2006/07/11 17:28 2006/07/11 17:28
내가 쓴 글/일기장  2006/04/17 17:41
세상에 완벽한 프로그램은 없다고 했건만,
작년 12월부터 지금까지 4개월간을 끌어오며 만들던 게시판 소스를 지켜보다가 그간에 공부하면서 변화된 인식과 너무 많이 차이난다는 것을 느꼈다.

UTF-8로 인코딩하는 문제, 표준준수에 관한 것, PHP 언어에 대한 개념 재정립 등등 그간에 변화한 인식과 프로젝트가 진행될수록 증가하는 복잡도의 압박을 이기지를 못하고 대대적인 리팩토링 작업에 들어갔다.

XP개발법을 지향한다고 딱 잘라 말하기보다도 프로그래밍 스타일을 그렇게 가져가고 싶다.
간결하고 즉흥적인 구현에 초점을 두고 작업한 뒤, 리팩토링을 통한 정리가 나의 목표다.

서버도 노트북의 로컬서버로 옮겨버리고 소스를 죄다 다운 받은 뒤, 열심히 리팩토링 중.
스스로에게 "이 고비를 넘겨야 된다"라고 주문을 외워보지만, 너무 꼬여버린 프로젝트를 이대로 이끌어갈 수가 없었다.

그리하여 대대적 개편.
그렇다고 코드를 버리지는 않는다.


하루종일 이걸 새로해, 계속해, 수정해를 고민하며 보냈다.
시간아까워 -_-;;
2006/04/17 17:41 2006/04/17 17:41
# 폼과 URL에서 데이터를 처리할 때의 일반적인 공격 유형
  • 크로스 사이트 스크립팅 ( XSS, cross-site scripting )
  • 크로스 사이트 리퀘스트 위조 ( CSRF, cross-site request forgeries )
  • 스푸프 ( spoof )


# 코드 안에 직접 작성한 데이터는 신뢰할 수 있는 데이터라고 간주한다.
# 원격소스에서 가져오는 모든 것을 입력이라고 하며, 모든 입력(검증된 것이라고 보장할 수 없는 모든 데이터)은 오염된 것으로 봐야하므로 반드시 필터링을 한 후에 데이터를 이용해야 한다.



# 사용자가 응용프로그램에 데이터를 전달하는 방법
  • URL ( GET 데이터 )
  • 요청의 컨텐츠 ( POST 데이터 )
  • HTTP 헤더 ( 쿠키 )


# PHP 파일 업로드, 이론상의 위험

사용자의 코드에서 업로드된 파일을 검증하지 않고 tmp_name(업로드된 원본 파일의 임시보관 파일)을 사용한다면 공격자가 tmp_name을 수정하게 하는 익스플로잇을 사용할 수 있다.

해결책 : is_uploaded_file(), move_uploaded_file() 함수의 사용
  1. is_uploaded_file() : tmp_name이 참조하는 파일이 업로드된 파일인지 검사
  2. move_uploaded_fie() : 업로드된 임시파일(tmp_name)을 저장할 위치로 옮긴다. 이 함수는 오직 업로드된 파일에 대해서만 적용가능하다.


# 보안에 있어서 가장 좋은 지침은 적게 믿는 것이다.



# $_REQUEST에 대하여

$_REQUEST는 GPC(Get,Post,Cookie)에 모두 적용가능한 슈퍼글로벌 변수이므로 POST데이터로 예상했던 변수에 GET데이터를 삽입할 수도 있다. CSRF(크로스 사이트 리퀘스트 위조) 공격이 이런 식으로 이뤄지기 때문에 $_REQUEST를 사용하는 것은 권장되지 않는다.

해결책 : 처리를 수행하는 HTML 폼에서는 GET대신에 POST를 사용하고(RFC2616 9.1.1), 폼 로직 처리에서는 $_REQUEST대신 $_POST를 사용한다.

사용자의 편의성은 위험을 증가시킨다. 사용자 편의성과 위험 사이의 적절한 균형을 찾는 것이 필요하다.



# HTTP 헤더의 신뢰성에 대하여

이전 페이지의 정보를 가지고 있는 레퍼러(Referer)의 비교를 통해 폼에서 넘어온 데이터가 믿을 수 있는 것이라고 단정지어서는 안된다. 헤더 정보는 조작이 가능하다.



입력 필터링의 중요성과 HTTP 요청에서 제공되는 어떤 것도 신뢰의 대상이 될 수 없다는 사실을 기억하라.
2006/04/13 10:50 2006/04/13 10:50

본인이 책을 보고 메모한 내용을 블로그에 정리한 것.

# 심층방어(Defense in Depth)
항상 예비계획을 가지고 특정 보호 수단이 실패하면 다른 보호 수단을 제공할 수 있어야 한다는 원칙


# 최소권한
불필요한 권한을 주지 않고 항상 최소한의 권한만을 제공하도록 한다.


# 유효하지 않은 데이터를 수정하려는 행위가 오류를 포함할 가능성이 높고, 잘못된 데이터를 통과시킬 수 있다.때문에 검사가 수정보다 훨씬 더 안전한 대안이 된다.


#
검사 프로세스 이외에 화이트 리스트를 사용한다.( 화이트리스트 : 데이터가 유효하다고 증명되지 않은 것은 모두 유효하지 않은 것으로 가정하는 것 )


# 정규표현식 보다는 PHP함수를 사용하는 것이 언제나 더 바람직하다. 직접 작성한 코드는 PHP 함수보다 더 많은 오류를 가질 가능성이 높다.


# 출력 이스케이프
- 순서상으로 필터링이 먼저고, 그 다음이 이스케이프 단계다.
- htmlentities();
- 모든 데이터를 일관되게 이스케이프하는 것은 응용프로그램의 보안을 매우 효과적으로 향상시키는 좋은 습관이다.
- SQL 쿼리는 가능한 한 데이터베이스에서 제공하는 함수들을 사용해서 이스케이프한다. mysql_real_escape_string();


# 엄격한 명명규칙
- 필터링된 데이터는 모두 $clean 배열에 저장한다.
- 이스케이프 된 데이터는 $html 배열에 저장한다. $html 배열은 ①빈 배열로 초기화하고②필터링과③이스케이프를 모두 거친 데이터만 갖는다.
- $clean, $html은 항상 비어있는 배열로 초기화하라!! -> $clean = array();

<?

// 배열을 초기화
$html = array();


// $clean['username']은 필터링된 데이터로써
// clean안의 모든 변수를 필터링된 데이터로 간주하는 습관을 가지라
$html['username'] = htmlentities ( $clean['username'], ENT_QUOTES, 'UTF-8' );


echo "<p>Welcome back, {$html['username']}.</p>";

?>


2006/04/11 09:34 2006/04/11 09:34
LastPlan.exe

↑ 실행파일






내가 만들고도 참으로 허접하여 어이가 없는 프로그램.
노란 박스의 플레이어가 날아오는 흰 적들을 피하는 게임이다.
그러다 부딪히면 죽는거고...

게임은 어이없게 간단하지만, 이 속에는 내가 이해해야 할 수많은 개념들이 담겨있었다.
더블버퍼링, 크리티컬섹션, 멀티쓰레드, 충돌처리, 스크롤처리 등등등..
이 게임을 만들기 시작한 것이 한달전인듯한데 이것저것 공부하며 하다보니 오래도 걸렸다.
감격에 겨워 블로그에 포스팅 중..

정말 아무것도 아닌것처럼 보이는 이 프로그램.
하지만 보면볼수록 흐뭇하고 내 자식같은 느낌이 전해져온다.

참고자료로 뽑은 15페이지 1500줄짜리 소스가 담긴 A4용지가 너덜너덜 해졌다.
너덜너덜 한 채로 노트북 옆에 널부러진 이 종이뭉치를 바라보니 그간의 고통이 전해져 오는 듯 ㅠ.ㅠ

이렇게 독학의 세계는 멀고도 멀다. 어흑..
2006/04/07 23:02 2006/04/07 23:02
lunstar:달리자
달리자
전체 (880)
내가 쓴 글 (796)
주제별 이야기 (59)
GhostX (1)
사진첩 (7)
Project Suwonsung (2)
동영상 (2)
Programing (0)
아이폰 개발 (11)
«   2012/05   »
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
  1. 2011/03 (1)
  2. 2011/02 (2)
  3. 2011/01 (3)
  4. 2010/12 (3)
  5. 2010/11 (3)
  6. 2010/10 (3)
  7. 2010/09 (5)
  8. 2010/08 (6)
  9. 2010/07 (6)
  10. 2010/06 (11)
  11. 2010/05 (12)
  12. 2010/04 (13)
  13. 2010/03 (16)
  14. 2010/02 (13)
  15. 2010/01 (11)
  16. 2009/12 (11)
  17. 2009/11 (20)
  18. 2009/10 (11)
  19. 2009/09 (8)
  20. 2009/08 (10)
  21. 2009/07 (11)
  22. 2009/06 (10)
  23. 2009/05 (10)
  24. 2009/04 (8)
  25. 2009/03 (10)
  26. 2009/02 (9)
  27. 2009/01 (14)
  28. 2008/12 (13)
  29. 2008/11 (10)
  30. 2008/10 (11)
  31. 2008/09 (4)
  32. 2008/08 (8)
  33. 2008/07 (12)
  34. 2008/06 (16)
  35. 2008/05 (15)
  36. 2008/04 (18)
  37. 2008/03 (14)
  38. 2008/02 (9)
  39. 2008/01 (14)
  40. 2007/12 (13)
  41. 2007/11 (12)
  42. 2007/10 (16)
  43. 2007/09 (16)
  44. 2007/08 (20)
  45. 2007/07 (18)
  46. 2007/06 (16)
  47. 2007/05 (22)
  48. 2007/04 (24)
  49. 2007/03 (30)
  50. 2007/02 (19)
  51. 2007/01 (32)
  52. 2006/12 (26)
  53. 2006/11 (23)
  54. 2006/10 (27)
  55. 2006/09 (31)
  56. 2006/08 (18)
  57. 2006/07 (39)
  58. 2006/06 (33)
  59. 2006/05 (25)
  60. 2006/04 (34)
  61. 2006/03 (2)

RSS News

RSS News Change