php 계정 생성
글쓴이: oppa / 작성시간: 금, 2014/09/12 - 12:27오전
죄송합니다. 숙제인데 너무 초보라 여기에 올립니다.
고수님들 한수 부탁드립니다.
username 은 4-10 characters, password 는 6-14 characters 로 만들는 것입니다.
일단 html 파일은 첨부했습니다.
그리고 아래에 php 파일을 생성했습니다.
<?php
echo "User Name: " . $_REQUEST['urname'] . "" . "<br />";
echo "Password: " . $_REQUEST['pass'] . "" . "<br />";
echo "Email: " . $_REQUEST['email'] . "" . "<br />";
switch ($_REQUEST['gender'])
{
case 0:
$gender = "Female";
break;
case 1:
$gender = "Male";
break;
}
echo "Gender: " . $gender . "";
?>File attachments:
| 첨부 | 파일 크기 |
|---|---|
 myaccount.html | 622바이트 |
Forums:
<?php $req = (object)
이걸 원하시는 건가요?
그리고, web을 통해서 전달되는 변수는 _REQEST보다는 _GET 이나 _POST로 정확히 구분을 해서 사용하는 것이 보안상 좋습니다. POST로 넘기는 변수를 GET으로도 처리할 수 있게 된다면 injection이나 공격에 취약해 집니다. (_REQUEST는 _POST와 _GET을 구분하지 않고 사용하는 것입니다.)
감사합니다.
그런데 이메일 입력시 이메일 형식이 아닌것 알려주고 다시 입력하라는 것은 어떻게 하나요?
preg_match 함수와 정규 표현식에 대해서
preg_match 함수와 정규 표현식에 대해서 공부를 해 보시기 바랍니다.
또는, 구글에서 "php email 체크"로 검색해 보셔도 될 듯..
?
POST 로 넘기는 변수를 GET 으로 처리할 수 있다고 해서 보안상 더 문제가 될 일은 없습니다.
어차피 GET 이든 POST 든 COOKIE 든 이런 클라이언트 단에서 넘기는 값들은 전부 조작 가능합니다.
물론 그럼에도 불구하고 구분해야 좋은 이유는 좀 더 명확하게 표현하기 위해서입니다.
(또는 COOKIE 와 POST 에 같은 이름의 인자가 있을 수도 있고)
기술적으로 된다 안된다를 말하는 것이 아닙니다.
기술적으로 된다 안된다를 말하는 것이 아닙니다. 습관을 의미하는 것이죠. 하나를 무시하기 시작하면, 보안성은 떨어지기 마련입니다.
받기 전에 GET이냐 POST냐 따져봤자 아무 의미
받기 전에 GET이냐 POST냐 따져봤자 아무 의미 없습니다.
둘 다 훤히 열린문이니까요.
보안을 위해서라면 GET와 POST를 구분 하던 안하던 상관없이
그 뒤에 유효성 검사를 거쳐야 합니다.
윗분 익명 말이 정확합니다.
기술적인 얘기가 아니라고 하는데 참.. :-)
기술적인 얘기가 아니라고 하는데 참.. :-)
요즘은 보안은 이미 기술적인 부분은 의미가 없습니다. 얼마전 미국의 기자가 자신의 icloud 계정을 해킹한 크래커에게 신고를 하지 않는 전재로 해킹 경위를 물어서 포스팅한 글이 있었는데 (mobile facebook에서 본거라 출처는 기억나지 않음) 그 경위를 보면 기술적인 부분은 거의 없이 계정을 털수 있었습니다.
이 예로 보아서는 단순하게 보안이라는 것이 이 방법으로 가능하다 아니다를 따지는 것은 무의미 하다는 것을 의미합니다.
뭐 제가 GET/POST를 어떻게 처리하는지 잘 몰라서 그런 글을 썼을까요? GET/POST 구분을 잘 하는 것 부터가 시작이라는 의미입니다. 용도에 맞게 정의된 것(_GET/_POST)가 있는데 편의를 위한 (_REQUEST)를 이용하는 것은 좋은 습관이 아니니 고치라는 의미입니다.
윗분 말씀대로 아무리 후처리를 잘하더라도, 한순간의 실수로 hole이 생깁니다. 요즘의 보안 hole은 몰라서가 아니라 coding 중 실수나 의도치 않게 발생하는 것이 대부분이라고 할 수 있습니다. 그러니 정확하게 코딩하는 습관을 가져야 한다는 의미를 말하는 겁니다.
그리고, _GET/_POST의 보안성이라는 것은, 요즘은 bot이 그냥 막 뒤지기 때문에 말씀하신 대로 의미가 없을 수는 지만, 사람이 직접 무언가를 해 볼 경우에는 분명히 확률은 떨어뜨릴 수 있습니다. 예를 들어 GET의 경우에는 browser(text browser)로 한번 대충 찔러 볼 수 있지만, POST의 경우에는 GET 보다는 어쨌든 불편하게 시도를 해 봐야 합니다. 즉, 보안의 경우 불편할 수록 보안성이 높아지게 되므로 GET/POST 구분이 전혀 의미가 없다고 할 수는 없다는 의미입니다. (찔러보기가 편할수록 시도할 수 있는 개체의 수가 많아진다는 의미입니다.)
POST로 넘기는 변수를 GET으로도 처리할 수 있게
POST로 넘기는 변수를 GET으로도 처리할 수 있게 된다면 injection이나 공격에 취약해 집니다.일반적인 습관 얘기가 아니라 injection에 대해 명확히 지정해서 기술적인 내용을 말씀하셨으니
계속 그에 대한 말이 나오는거 아닙니까.
?
"그리고, web을 통해서 전달되는 변수는 _REQEST보다는 _GET 이나 _POST로 정확히 구분을 해서 사용하는 것이 보안상 좋습니다.
POST로 넘기는 변수를 GET으로도 처리할 수 있게 된다면 injection이나 공격에 취약해 집니다."
위에서 이렇게 말씀하셔놓고 습관 얘기를 꺼내는 건 본인이 생각해도 좀 이상하다고 생각하시지 않습니까?
그러면 처음부터 이유를 그렇게 말씀하셔야지, 저렇게 얘기하면 듣는 사람들에 따라선 정말로 $_REQUEST 를 쓰면
보안상 문제가 많구나 라고 오해할 수 있습니다. 그래서 제가 아래쪽에 따로 부연 설명을 한 것입니다.
저도 사정상 현재는 웹 프로그래머로 일하고 있고, 저 역시 $_REQUEST 는 거의 쓰지 않습니다.
그러나 그 이유는 각각에 맞게 정의된 것이 있으니 더 명시적으로 확실히 표현하기 위한 이유이지 보안상의 문제 때문은 아닙니다.
"세상에 GET POST REQUEST 등이 보안적으로는 의미 없다는거 모르는 사람이 어디있냐?" 라고 생각하실 수도 있는데,
웹 프록시 툴 한번 써본 적 없고 존재조차 모르는 사람들(심지어 웹 프로그래머조차) 많습니다.
글로 하는 communication은 참 안좋다는
글로 하는 communication은 참 안좋다는 것을 다시 한번 느끼네요.
서로 보고 싶은 것만 보고 자신의 관점에서만 이해를 하는 것 같습니다. :-)
기술적인 언급이 아니라고 했고, 말씀하신대로, 너무 간략하게만 적어서, 그 다음에 그 이유에 대해서는 분명히 써 놓았습니다. 다만 제가 잘못한 것이라면 첫 문장이 좀 비아냥 거리는 것 처럼 보일 수는 있겠네요. :-)
다만, GET/POST의 문제는 분명히 injection에 취약 합니다. 대부분의 bot들이 공격을 시도할 때 GET으로 시도를 하기 때문에 재수없으면 그냥 걸리는 것이 문제가 될 수 있습니다. 이부분만 잠깐 언급을 하자면, bot이 web에서 URL을 구해서, URL parameter의 argument 값에 공격이 가능한 값을 무작위로 입력을 하는데, 이 경우, GET/POST 구분만 잘 해 줘도 공격을 막을 수 있기 때문입니다. 이런 공격이 얼마나 될 것 같냐고 하시겠지만, KLDP에 들어오는 공격 시도 중 70%가 이런 유형입니다.
저는 일단 여기까지만..
?
GET 으로만 시도한다는 그 "대부분의" bot 들이 무엇인지, 그 근거는 어디서 얻으셨는지 제시해주실 수 있을까요?
쭉 보안 업계에서 몇 년 넘게 일했었고 예전엔 많은 mass sql injection 툴들이나 중국발 봇들 분석이나 하고
웹 스캐너 개발이나 해와서 그런지 저는 생전 처음 듣는 내용인거 보면 굉장히 신선한 내용이라고 생각됩니다.
언제적 얘기인지 모르겠지만 요즘 get post 관계 없이 web response 에서 form 파싱해서 전부 시도해보는
스캐닝 유형은 매우 일반적인 유형입니다. 이젠 그냥 당연하다고 생각되고 있는게 보통입니다.
제 경우는 자신의 관점에서 이해하려는 경향이 강한 건 사실입니다. 글로 하는 커뮤니케이션뿐 아니라 오프라인에서도 비슷합니다.
상대방의 얘기에 수긍하기 위해선 먼저 철저한 근거와 사실에 입각한 내용이 아니라면 절대로 수긍을 하지 않습니다.
그래서 저는 정확히 모르는 내용이라도 검색을 며칠에 걸쳐서 하고 나서 확실히 정리가 되면 대응합니다.
그런데 이번엔 애초에 제 전공이다보니 굳이 검색할 필요는 없는 것 같습니다.
그저 제 3자에게 조금 더 구체적으로 보충 설명하려고 한 짧은 댓글이 왜 이렇게 되었는지 모르겠네요 ;)
근거는 (KLDP또는 회사의 웹서버, 제
근거는 (KLDP또는 회사의 웹서버, 제 개인서버)로그 분석에 근거 합니다. 대부분의 공격 시도가 GET 이어서 입니다.
그리고, 저는 보안이 전공은 아닙니다만, 시스템을 운영하는 입장에서의 방어에 대해서는 연구를 꽤 한 것 같습니다. (실제로 KLDP가 뚫렸을 때 어떻게 뚫렸는지 분석을 해서 복구를 했고, 더이상 뚫리지 않도록 잘 방어하고 있는 것 같고.. ^^ https://kldp.org/node/45576 참고)
그러다 보니 bot이나 기술적인 부분에 대해서는 전공하신 분들만큼 잘 얘기할 수는 없습니다만, 동향이라든지, 뚫린 case는 많이 접하고 경험하기 때문에 문제가 된다 안된다고 말할 수 있을 것 같습니다.
그래서 윗글에서 결국에는 view point의 문제인 것 같다고 말씀 드린 것이고요. (개발에서 보는 관점이나 보안에서 보는 관점이나, 운영에서 보는 관점들이 얘기를 나누다 보면 focus가 다른 것을 절실히 느낄 수 있으니까요)
P.S.
기분이 상한것은 없습니다. 그냥 의사 전달의 한계에 대한 푸념일 뿐인거죠 ^^; 글이라는 것이 어떻게 잘 전달하려고 노력하더라도 감정 싹 빼고 전달이 되는 것이고, 생각하는 바를 전부 다 나열할 수 도 없으니 말이죠.
?
덧붙여서 조금 기분 나쁘게 얘기한 것에 대해 사과드립니다.
그래서 아래 진술이 참입니까? POST로 넘기는
그래서 아래 진술이 참입니까?
가설 설정과 검증이 잘못되었습니다.
위 가설이 참임을 증명하려면
전체 공격 중에 GET을 통한 공격이 차지하는 비율을 검사하는 것이 아니라
전체 공격 중에
GET으로 받는 데이터에 POST를 통해 injection 공격을 시도하는 경우 +
POST으로 받는 데이터에 GET을 통해 injection 공격을 시도하는 경우의 비율을 재야 하는 겁니다.
설혹 그 비율이 높게 나왔다 하더라도 아주 무의미한 결과일 뿐입니다.
위의 말을 하신 분조차도 잘 알고 있을 겁니다. injection 공격하고 GET/POST 구분하고는 전혀 별개의 문제인걸.
injection 공격은 GET으로 받는 데이터에 GET으로 공격을 해도 후처리가 안되어 있으면 뚫리는 상황인데
대체 GET/POST 구분이 무슨 의미가 있습니까?
본인도 모르지는 않을 거에요.
그냥 인정하고 싶지 않을 뿐이지.
뭐 이렇게 얘기가 끝나나 어이가 없을 뿐입니다.
증명은 딴지를 거는쪽에서 하는 겁니다... 상상만
증명은 딴지를 거는쪽에서 하는 겁니다...
상상만 하시마시고 확실한 증거를 제시해 보세요..
그냥 인정하고 싶지 않을 뿐이지솔직히 이 문장은
그냥 인정하고 싶지 않을 뿐이지솔직히 이 문장은 기분이 나쁘네요. 그리고, 어이가 없을 이유는 뭔가요? 보는 관점이 다르고, 여기다 강좌를 쓸 수도 없고, 그래서 토론이 제대로 될것 같지도 않아서(토론 게시판도 아니고) 그만하자고 했는데 말이죠.
기술적 관점이 아니라고 설명을 하면, 윗분처럼 어떤 거냐고 물어 보시는 것이 맞지, 제 말이 맞다 틀렸다라고 단정지으실 필요는 없을 것 같아서 하는 말입니다.
이렇게 기술적으로 공격을 당하는 것도 오랜만이라 새삼스럽군요 :-)
저도 궁금한 것이, 기술적 관점이 아닐 경우(이걸 이해 못하시는 것일지도 모르지만)에 GET/POST 구분이 injection에 취약하지 않다고 장담하실 수 있나요? 공격 비율을 얘기한 것은 질문하신 분의 질문에 대한 근거이지, 제가 말하고자 하는 바의 근거가 아닌데요.
그리고, 정말 GET/POST 구분을 안해도 100% injection을 당하지 않는다고 장담하실 수 있으신가요? 코드를 만들 수 있는 사람이 전부 다 개발자라고 생각을 하시나요? 전부다 이런 어이없는 실수는 하지 않을 사람들만 있다고 생각하시는 가요? 보안에 빠삭한 사람은 실수를 안할 것이라고 생각하나요?
전 GET/POST 구분이 injection에 취약하다고 말하는 것은, 이런 소극적인 방어기법 부터가 보안을 생각하고 코드를 짜는데에 대한 기본이라고 말하고자 하는 겁니다. 방어코드를 잘 짜야 한다라는 논점은 우리 같은 사람만 있다고 생각하는 것과 같다고 생각합니다. 그래서 기술적인 관점이 아니라고 계속 얘기하고 있습니다.
그래도 GET/POST가 Injection에 취약하다는 증명을 해야 한다고 말씀 하신다면, 서로에게 더이상 얘기를 할 필요가 없지 않을까 생각합니다. 님은 저를 "인정하기 싫은 편협한 놈"으로 보고 있다는 것일테고, 저는 "상대방을 이해하려 하지 않는 사람"으로 보게 될테니까요.
P.S.
제가 위에 질문을 한 것은 답변을 원하는 것이 아닙니다. 다른 관점에서 생각을 해 보시라는 것입니다. 괜히 답변하지 마세요. 자신의 생각과 다름을 잘못 되었다라고 하시는 분과는 더이상 쓰레드를 이어나갈 생각은 없습니다. 그리고 토론을 원하신다면, 네가 잘못 되었다가 아니라 너는 왜 그렇게 생각하니 라고 표현해 주세요. 그렇다고 해서 계속할 생각은 없습니다. 제 입장을 굳이 님께 이해시킬 필요는 없고, 여기는 토론 게시판도 아니며 이미 질답에 대한 부분이 해결이 되었다고 생각합니다. 잘못된 것을 정정해야 한다는 것은, 님이 잘못된 것이라고 생각하는 것이 저는 잘못된 생각이라고 판단하기 때문에, 굳이 평행선을 달리는 시점에서 토론은 무의미할 것 같아서 입니다.
아 그리고, 윗분이 의문을 제기하신 부분은 여기서 정답을 낼 필요는 없을 거라 생각합니다. 의문이 나시는 분들은 공부를 해 보시고 판단을 해 보시면 될 문제로 보입니다. GET/POST 구분을 하지 않는 것이 injection에 취약하다는 의견과 취약하지 않다는 의견이 서로 팽팽한 상태이니, 궁금하시면 파보도록 하세요. 이 쓰레드에서는 저도 취약하다는 것을 증명하지 않았지만, 제가 보는 입장에서는 취약하지 않다라는 것도 증명되지 않았습니다. 충분히 반론을 할 수 있는 코드를 제시할 수 있을 것 같거든요. :-)
아 그리고 하나 추가하자면.. 질문이 PHP이고,
아 그리고 하나 추가하자면.. 질문이 PHP이고, PHP에서는 GET/REQUEST의 경우에는 PHP engine에서 몇몇 character들을 자동으로 변환을 합니다. 그리고 PHP의 경우에는 대부분의 문자열 함수들이 binary safe하기 때문에 %00 같은 것들이 문제가 되는 경우가 많기 때문에 메뉴얼 상에서도 _GET/_REQUEST는 사용 권고를 하지 않고 있습니다. 그래서 중요한 데이터들은 _POST를 사용하라고 권고하고 있습니다.(_POST는 PHP가 가공을 하지 않습니다.)
뭐 이건 쓰레드의 논지와는 조금 다른 정보이지만, GET/POST에 대한 얘기가 나온김에 하나 더합니다.
그리고, 여기에서의 논지는 전 PHP의 _GET/_POST 전역변수에 대해서 얘기를 한 것인데, 어쩌다 보니 GET/POST에 대한 것으로 논지가 확장이 되기는 했습니다. (그렇다고 제 입장이 다르지는 않습니다. 뭐 어차피 그게 그거이기 때문에..)
댓글 달기