네이버에서 만든 노무현 전 대통령 추모 게시판을 보다가 우연히 본 문제인데 좀 심각하다 싶어 같이 공유하고 생각해 보고자 한다.
직업병인지 몰라도 항상 어떤 웹 페이지를 보면 HTML 소스를 보는게 일상적이다. 아무 의심없이 추모 게시판 HTML 소스를 열어 보는데 난데 없는 욕설에 깜짝 놀랐다.
추모 게시판 방명록 입력 시 욕설을 필터링 하기 위해 모아둔 키워드 목록이었는데 세상에 이렇게 많은 욕설이 있었는지 상상을 초월할 정도였다. ㅎㅎ
실상 문제는 이 욕설 단어가 아니라 단어 입력을 자바스크립트로 필터링을 하고 있는 사실이었다. 따라서 아마 똑같은 작업을 백엔드 프로그램에서는 하지 않을 것 같다.
웹 개발의 가장 중요한 불문율 중에 하나가 프론트 엔드, 즉 UI 영역에서 유효성 확인(Validation)을 믿지 말라는 것이다. 사용자 데이터 유효성 확인은 꼭 백엔드 프로그램에서 이루어져야 한다. 이는 보안 취약성을 제거해 줄 뿐만 아니라 견고한 웹 프로그래밍의 기초가 되는 사실이다.
지금은 문제가 된다고 판단해서인지 escape로 인크립션이 되어 있지만 unescape을 하면 쉽게 다시 풀 수 있다. 웹 개발자와 프론트 엔드 개발자가 협업이 안되고 있다는 증거인 듯.
두번째는 Ajax의 남용이다. 이 방명록 소스를 보면 글 목록, 글 삭제 등등이 모두 Ajax로 구현이 되어 있다. 한마디로 자바스크립트를 끄면 전혀 동작이 안되는 웹 사이트이다. Ajax의 남용의 대표적인 사례이다.
자바스크립트 없이 간단한 글 쓰기 조차 안되는 것은 방명록 같은 간단한 애플레키에서 보기 힘들고 웹 접근성에 있어 최악의 사례이다. (참고. 애플리케이션 개발시 Ajax를 사용해야 할 부분과 시점)
특히나 로직 노출 역시 큰 문제이다. 프론트엔드에서는 가급적 웹 프로그램의 로직이 보이지 않도록 해야 한다. 해킹에 바로 취약해 지기 때문이다. 웹 프로그램이 어떻게 짜여 있는지 이렇게 훤히 보이도록 만들어 둔다는 건 문제다. 이거 무슨 오픈 API도 아니고…
네번째는 중요한 개인 식별 정보의 노출이다. 26일 오후 1시까지 대략 50만명이 추모글을 쓴 시점에서 네이버 아이디가 노출되어 있었다. 포털 서비스 특히 메일 서비스를 함께 운영하는 회사에서 아이디 서비스 노출은 매우 큰 문제이다.
아이디 유출은 곧 스팸 메일 공격으로 이어지는 개인 정보이기 때문이다. 따라서 식별 정보는 닉네임을 노출시키는 것이 가장 일반적이다. 그런데도 50만명이 넘는 아이디 정보가 노출되었다. (26일 오후 4시쯤인가 아이디 뒷자리를 ****로 표시하도록 고쳐졌다.)
문제는 이 게시판은 고쳐지긴 했지만 이런 중요한 문제에 대한 내부 규율이 아직 제대로 동작하지 않고 있다는 점이다.
네이버가 소통을 위해 열어두었던 고객 센터 게시판의 3만개가 넘는 글에도 여전히 아이디는 노출되고 있다. (1년 이상 쭉…) 다들 네이버 불평불만 세력(?)으로 보이는데, 블랙 리스트도 아니고…
이러한 문제들은 웹 개발할 때 꼭 알아야 할 상식과 같은 것들이다. 개발자들이 흔히 저지르는 실수들이니 꼭 알아두시길…
update. 오해가 있을 것 같아 적어두자면 이 글은 원래 일요일에 썼지만 스스로 고칠 수 있도록 3일 정도를 기다린 후 수요일에 공개한 것입니다. 즉, 아이디를 ****로 막고 금칙어를 escape 처리하도록 기다린 후에 공개했기 때문에 이 글을 통해 아이디 정보가 나가거나 하지는 않았을 겁니다. (즉 취약성이 고쳐진 후 문제를 공유했다고 보는 게 맞습니다.)
※ Disclaimer- 본 글은 개인적인 의견일 뿐 제가 재직했거나 하고 있는 기업의 공식 입장을 대변하거나 그 의견을 반영하는 것이 아닙니다. 사실 확인 및 개인 투자의 판단에 대해서는 독자 개인의 책임에 있으며, 상업적 활용 및 뉴스 매체의 인용 역시 금지함을 양해해 주시기 바랍니다. 본 채널은 광고를 비롯 어떠한 수익도 창출하지 않습니다. (The opinions expressed here are my own and do not necessarily represent those of current or past employers. Please note that you are solely responsible for your judgment on checking facts for your investments and prohibit your citations as commercial content or news sources. This channel does not monetize via any advertising.)
잘 봤습니다. 요즘 유행하는 음모론으로 볼 때 네이버 불평불만 세력 아이디 노출로 스팸 메일 폭탄 맞게 하려는 노림수? 후훗.
그러고 보니 다음의 게시판 소스 코드와 진짜 대조되네요 .
http://condolence.media.daum.net/gaia/do/service/commentList?bbsId=Notice&articleId=1
http://campaign.naver.com/comment/list.html?code=promotion_nomuhyeun
다음의 게시판 역시 js파일 안에 로직을 어느 정도 노출해 둔것은 똑같습니다. 이 글에 적어둔 문제는 많은 ajax 기반 서비스에서 나오는 근본 문제 중에 하나입니다.
저는 날밤 블로그를 운영하며, 3년전까지 네이버 해피빈에서 일했고, 올해 초 네이버의 자회사로 입사한 날밤이라고 합니다. 평소 개발에 관하여 관심도 많아 다음의 데브데이에도 참가 했었고. 윤석찬님도 몇번 뵈었고, 블로그 포스트도 구독 하고 있었습니다. 최근에는 트위터에도 팔로우를 했군요. 그러다 오늘 좀 당황스런 포스트를 읽게 되었네요. 웹 개발 시 저지르는 실수들 네. 저희 잘못 인정합니다. 급히 만들다 보니 놓힌 부분도 많았고요. 서둘러 수정도..
JS의 경우 로직이 드러나는 것은 어쩔수 없는것 아닌가요? 여러가지 어느정도 감출수 있는 방법이 존재하긴 해도 클라이언트사이드는 결국은 다 열어볼 수 있기 때문에 큰 의미는 없다고 생각합니다. js가 안될경우 글쓰기에 대한 대안이 없는 것은 문제입니다만 사용자에게 ajax가 편의선을 준다는 점에서 남용이라고 하기는 좀 어렵지 않나 생각합니다.
아이디의 경우도 남용될 여지가 있기는 하지만 어차피 아이디는 유니크값이기 때문에 가지고 있을수 밖에 없다고 생각합니다. 서비스따라 다르지만 블로그등의 주소를 아이디로 쓰는것이 일반적이기 때문에 아이디는 노출될 수밖에 없다고 생각합니다. 불필요한 노출은 막아야 겠지만 닉네임을 클릭했을때 쪽지보내기등의 기능을 구현하려면 어딘가에는 아이디를 가지고 있어야 하고 그렇게 되면 수집가능성이 있는건 어쩔수 없다고 생각하고 있습니다.
충분히 생각하신 문제라고 생각은 하지만 실수가 아닌부분도 있다는 지나가던 개발자의 의견을 슬쩍 남겨봅니다. ^^
우선 url에 로직이 있는 경우와 ajax로 그 응답값에 대한 처리와 설명을 자세히 하는 건 좀 차이가 있다고 봅니다만 이건 개발자들이 판단할 수 있는 문제라고 저도 생각합니다. 다만, 방명록 같은 간단한 서비스에서 이렇게 하는 게 문제라는 거구요. 예를 들어 과거에 header와 footer 같은 걸 script로 임베딩하던 황당 사이트와 비슷하다고 볼 수 있죠.
웹 사이트 아이디의 경우 대형 사이트의 경우 가급적 unique key로 쓰지 않는게 좋습니다. 아이디가 삭제되고 새로 만들어지면 히스토리관리도 안되구요. 아이디가 노출되는 개인 정보 문제도 있구요.
어쨌든 제가 보기에 문제라는 거고 의견이 다를 수 있다는 건 인정합니다.
쉽게 할수 있는 실수들에 대해서 잘 집어 주셔서 감사합니다.
마지막 까지 말끔해야겠군요
어익후.
다음의 경우 자바스크립트를 사용 안하면 로그인 자체가 안되는 군요.
또한 iframe 라서 넓어지지 않아 글이 안보여요.
어익후-
어익후 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
누가누가 이기나 함 결판 냈으면 좋겠네요 🙂
개발 1년차인 왕초보입니다(금융권). 아무리 그래도 저런 실수가 많은 사람이 다녀가는 싸이트에 만연되고 있다는데 충격을 금할 수 없네요.
그리고 위에 동종업계 까기라는 글 보고 참 맘이 착잡해지네요.
eriteia님]
그렇게 충격적인 내용은 아닙니다. ^^;
금칙어 라는게 일반적으로 wording 으로 100% 다 잡아 낼 수 있는게 아닙니다.
그래서 최근에는 스팸 필터링은 하는 알고리즘과 머신러닝을 통해서 다양한 방법으로 필터링을 하고 있구요.
하고자 하면.. 얼마든지 악의적으로 입력 가능 합니다.
위에서도 channy 님이 이야기 했지만 금칙어가 포함이 된게 문제라기 보다 one way 로만 checking 하는 부분과 server 단에서는 아무런 액션도 하지 않고 validation 을 검증 하지 않는다가 문제 입니다.
그리고 ajax 부분은 글쎄요.. 꼭 나쁘다고만 말할건 아닌듯 합니다. 🙂
암튼 front end 와 back end 다 중요하니.. 방심 하지 말아야 겠내요.. ㅎㅎ
전 금칙어를 언급하지는 않았는데요. 애매하게 쓰긴 했네요. 고객 정보 노출을 마음껏 할 수 있다는게 충격적이였다는 말이였죠
빨리 개발해야 되는데, 백엔드랑 프론트 엔드랑 맞추는데 금방 되겠습니다.
게다가 한국에서..
그냥 그렇구나 하면 됩니다.
제가 초보라 그러는데,
클라이언트에서 실행되는 js 파일에 로직이 노출 안되게 하는 방법이 있나요?
.js 파일을 다운받아서 보나 소스보기 해서 보나 똑같은게 아닌지요?
대개 웹애플리케이션에서 쉽게 서버쪽 로직을 파악하기 어렵해 하는 것이 중요한데요. js코드만 봐도 서버쪽 코드가 머리속에 훤히 그려지도록 만드는 문제점을 이야기 하는 것입니다.
그렇게 되면 예외 사항에 대한 파악이 쉽고 그만큼 해킹의 위험도가 높아지니까요. 이건 tradeoff할 만한 것이긴 하지만 가급적 자세하게 처리하지 않도록 만드는게 좋습니다.
js파일 자체를 보이게 어렵게 하는 것도 obscuration 같은 걸 쓰면 좋지요.
네이버 탈퇴혓어.
서버쪽에서 validation해야 하는것은 당연한 것이고, 금칙어가 있을 경우 서버로 요청을 보내는 것 자체가 낭비일 수 있기 때문에 클라이언트 레벨에서 미리 검사한 후에 서버로 요청을 보내도록 많이들 하고 있습니다. 차니님은 서버쪽 validation이 잘 이뤄지고 있는지에 대해서는 그냥 추측으로 마무리를 지으셨고요. 1번 “실수” 는 이 포스팅만 봐서는 실수일지 아닐지 알 수 없겠네요.
당연히 그렇습니다. 다만, 금칙어 목록 사이즈를 안 보셔서 그런데 아마 그정도의 크기면 서버에 ajax로 call 보내는 거나 비슷한 부하가 비슷할 겁니다.
미디어다음에서 플래시코드가 담긴 글을 등록시도시 실패했던 현상에 대해 다음에서 대응한 내용입니다.
글 등록후 욕설로 인해 등록되지 않았다고 결과페이지가 나왔었는데요, 해당 담당자는 아래와 같이 해명하더군요.
embed 태그를 막는 다음.. 조낸 실망했음 ㅠㅠ
안녕하세요, 고객님.
세상을 즐겁게 변화시키는 Daum 고객센터 미디어다음 담당자 ***입니다.
문의하신 게시물 등록에 대해 답변을 드리겠습니다.
우선, 고객님의 게시물이 정상적으로 등록하지 못해 대단히 불쾌하셨으리라 생각됩니다.
고객님께서 문의주신 내용은 태그의 금칙어 문제로 파악되오나, 이러한 금칙어 태그에 관한 정확한 문제점을 지적해드릴수 없는 점 양해해 주시기 바랍니다.
태그의 금칙어를 공개하면 본래의 금칙어 설정 목적에 어긋나게 됩니다. 따라서 공개가 힘든 점 너그럽게 이해해 주시기 바랍니다.
바로 도움드리지 못해 대단히 죄송합니다.
다른 궁금하신 사항은 언제든지 문의해 주시면 성실히 답변해 드리겠습니다.
웹 개발에서 저지르기 쉬운 실수를 사례 분석을 통해 밝히는 것도 물론 의미 있는 일이지만 그보다 중요한 건 ‘그러니까 대신에 이렇게 짜면 됨’이라는 가이드라인을 제시하는 거라고 본다. 개인적으로 직접 경험할 때마다 정리를 하긴 하는데 아무래도 경험이 제한되다 보니.
웹 개발 시 저지르는 실수들
아무 생각없이 이야기한다는 것은 깐다는 것과 동일한 의미가 될 수 있다.
석찬님이 경쟁사를 깍아내릴 의도가 있었다고 생각하지는 않습니다. 하지만 특정 회사나 브랜드 이름을 이렇게 직접 거론하지 않고 충고하는 방법은 없었을까? 라는 아쉬움은 있네요. 사람으로서 이런 비판을 감정 개입 없이 순수하게 받아들이기란 쉽지 않으니까요.
역시 일관된 네이버까..
차니님의 네이버 서비스에 대한 지적은 적절 했지만 동종업체끼리 이럴 수 있냐고 날밤님이 버럭했다. 이건 웃긴 일이다. 우리나라엔 쓸데없는 문화가 있는데 상대방의 입장을 파악하고 손익을 따져본다. 진정성을 확인하는 것. 이거 정말 비 이성적이고 비 생산적이다.
난 어떻게 해야 이런 글을 썼더니 이런 반응이 나오는지 이해가 안 간다. 네이버가 동네 슈퍼마켓 홈페이지도 아니고. 네이버쯤 되면 포스팅으로 까일 수도 있지. 까놓고 말해서 어떻게 조용히 말해줘야 바로 전달되서 고칠까?
전 자기블로그 검열의 글을 보고 엄청나게 실랄한 비판을 한 줄 알았습니다. 좀 실망했습니다. ^^ 이정도면 건전한 비판을 한 것 같은데.. 글쓴이가 다음에 속해 계시고 예을 든 포털이 네이버라는 것에서 오해의 소지가 있었지만요. 국내 1위 대형 포털이 그 정도 지적은 받을 수 있고 겸허이 받아 들여 수정하면 될 것 같네요.
단순 지적이 아닌것으로 보일만한 부분도 보이네요..
‘open API 아니고 참..’ 이라는 부분은 다분이 개인적인 감정을 드러내는 부분이 아닐까 라는 생각도 해보았습니다. open API 가 별거 있을까요? 거대포널 이라고 소스에 open API 쓰면 안된다는 것도 좀 그런거 같은데요?
문맥과 오픈API 언급을 잘 보십시오. 오픈API는 요청 그대로 데이터를 전달해 주는 읽기형(Read)형 서비스입니다. 요청-응답의 로직이 단순하죠. 특정 입력이 DB단 오류를 만들 수 있는 서비스에서 서버 로직을 그대로 그려질 수 있도록 만든 프론트단 js 코드에 대한 문제를 이야기한 겁니다. 개인 감정이 어디 있나요?
전 원래 답글을 잘 안달지만 상대가 경쟁사이기 때문에 배려 차원에서 이러고 있습니다.
설마 server 단에서도 validation check 는 하지 않을까요? 서버단 로직을 그릴수 있다고 하시는데 제가 보기엔 단순히 메세지를 번역한 수준의 로직인데요?
그외 method, 라든지 parameter 등등은 form 으로 하더라도 드러날수 밖에 없는 부분이구요.. ajax 안쓰고 form 전송방식으로만 넘겨도 대강은 로직 파악이 되지 않을까요? 윤석찬님의 말씀대로라면 말이죠..
다음검색 우측 실시간순위 검색어..
네이버 js 소스 그대로 베낀 흔적(변수명까지) 포스트로 올릴려다가 말았는데..
이젠 베낀거 있음 제대로 까발려서 망신줘야겠군요..
다음 이런식으로 나온다면.. 뭐..
마음대로 하셈. 옛날에 이런 일도 있었거든.
“네이버가 다음의 소스코드를 무단복제한 것으로 의심됩니다.”
http://www.smartplace.co.kr/blog_post_95.aspx
근데 이 글에서 지적한 문제랑 소스코드 서로 베끼기랑 뭐가 관련있나. 오독증 환자인듯.
실제로 원소스 네이버 이후 다음 카피 이후 네이버에서 다음카피한 내용이고, 다음 네이버 관련자 상호간에 종결한 것입니다. 위 문제를 아시고 말씀하시는 것인지??
문제점을 정확하게 집어주어 수정할수있는 기회를 준것이 비난받아야 되는지 알수가 없네요. 이렇게 글을 쓰지 않았으면 문제점이 더 오래 방치되어 수정되지 못했을 수도 있고 더 큰 문제가 발생했을지도 모릅니다. 왜 조용히 알려주지 않았느냐 하는 것은 잘못을 감추고 싶은 투정으로 밖에 보이지 않습니다.
좀 딴 얘기일지 몰라도 한국에서 전문적인 잡지나 신문에 전문적인 저널리즘이 사라지게 된 이유가 바로 그놈의 서로 봐주기 문화 때문이라고 생각합니다. 리뷰 기사 나오면 언제나 아 좋다, 이것도 좋고 저것도 좋다, 기자는 알지도 못하면서 업체에서 넘긴 말을 줄간격만 맞춰서 내보내고 하다 보니까 이제 독자들도 이런 미디어에 들어 있는 기사는 그냥 광고로 인식할 뿐입니다. 이제 그런 미디어의 기자들은 공정성이나 비판의 방법도 잊어버린 모양입니다.
계속해서 사람들이 문제를 감추고 서로 봐주기나 블로그들로 우리끼리 좋은 게 좋다는 글로 넘쳐난다면 인터넷의 글들도 결국 같은 운명을 걷게 될 겁니다. 아직 우리는 이것보다 훨씬 더 까야 됩니다.
특히나 로직 노출 역시 큰 문제이다. 프론트엔드에서는 가급적 웹 프로그램의 로직이 보이지 않도록 해야 한다. 해킹에 바로 취약해 지기 때문이다. 웹 프로그램이 어떻게 짜여 있는지 이렇게 훤히 보이도록 만들어 둔다는 건 문제다. 이거 무슨 오픈 API도 아니고…
“이거 무슨 오픈 API도 아니고…”
부분을 읽다가 방준영씨의 글을 읽는 줄 알았습니다. 말투가 하도 똑같아서요.
얼마전에 방준영씨에 의해서 개인적으로 많이 속상하셨을꺼라 생각하는데, 이런 비아냥의 말투가 상대를 기분상하게 하는 겁니다.
그런 부분에 대해서 당연히 ‘블로그 자기검열’을 해야합니다.
그냥 제 생각이에요.
문맥과 오픈API 언급을 잘 보십시오. 오픈API는 요청 그대로 데이터를 전달해 주는 읽기형(Read)형 서비스입니다. 요청-응답의 로직이 단순하죠. 특정 입력이 DB단 오류를 만들 수 있는 서비스에서 서버 로직을 그대로 그려질 수 있도록 만든 프론트단 js 코드에 대한 문제를 이야기한 겁니다. 개인 감정이 어디 있나요?
그리고 방준영씨 처럼 제가 특정 개인을 지칭한 건가요. 그냥 프로그램 소스 코드아닌가요. 이런걸 검열해야된다니.
“이거 무슨 오픈 API도 아니고…”
글쎄요, 저는 아무리 읽어봐도 이 부분이 비꼬는 말투로밖엔 느껴지지 않는데요.
남이 봤을 때 충분히 비꼬는 말투로 느껴진다는 것을 말씀드리는 겁니다.
제 개인적인 의견으로는,
프론트엔드 로직은 모두 open api 가 되는 것이
오히려 바람직하고 그것이 보안이슈든 UX든 효과적이라고 생각합니다.
-RESTful 파이팅~!
전 글을 읽다보니… 왠지 개발하면서 일어난 실수를 꼬집는게 아니라… 네이버 자체의 문제를 끄집어내고싶어하는듯한 느낌이 드는 건 왜일까요??????
어려운 일은 전문가에게..
ㅎㅎ.. 이거.. 전 업계가 좀 달라서.. 좀 객관적으로 얘기를 할 수 있으리라 생각이 되는데요..
전체적인 맥락은 맞는 얘기인 것 같습니다.
글 쓰신 분의 신분이 약간 문제인 것 같네요.
같은 말을 해도 상황에 따라서는 “똥묻은개가 겨묻은개를 나무라”는 꼴이 될수가 있으니까요.
이런 일에 대처하는 나의 방식: 전부 아니면 전무. 감정 이입시켜봤자 괜히 나만 피곤해진다.
이런 내용을 모르는 개발자가 있을까요?
(아마도… 귀사에서는 모르는 사람이 한명도 없는 모양이네요)
다른 내부 사정으로 급히 오픈하다 보니 실수가 있지 않았을까요?
(아마도… 귀사에서는 무결점 서비스만 제공하나 보네요)
확실히 알고 있는 것! 보이는 것! 만 가지고 얘기해야 합니다. 즉 fact만 가지고 얘기하세요~
‘아마도 백엔드에서는…’ 라고 쓰신 것을 보니 정확히 아는 바가 없으시군요.
그렇다면 이런 식으로 표현해서는 안 되는 겁니다.
잘못된 부분을 지적하는 것은 좋습니다.
당신의 명성(?!)에 맞게, 품위있게 적어 주시면
많은 공감을 이끌어 냈을 겁니다.
부끄럽지만…
이런 식의 표현은 제가 스무살 때 쓰던 방식입니다.
좋은 글 감사합니다. 덕분에 잘 배웠네요 ^.^
그런데 위에 트랙백과 댓글을 보니 꽤나 controversial한 포스팅이 되어버렸군요. 비판을 받아들이기 힘들어하는 분들이 꽤 계시군요.
제 생각에는 개인 블로그에 충분히 포스팅할 수 있는 내용입니다. 유명하면 시비거는 사람도 많군요 ^^;
와// 댓글 장난 아니다
근데 충분히 공감이 가면서도. 한편의 걱정을 이야기한 것 처럼들리는데 실제로 작업한 사람들에게는 기분나쁜 의미로 다가올 수 있겠다는 생각이 드네요. 하여튼 서로 싸우지는 맙시다.
프론트엔드쪽을 개발시는 분이시라면 form을 submit하기전에 javascript로 검증하는 소스를 많이 개발해 보셨을텐데요. 할때마다 귀찮기도 하고 손이 많이 가는 부분이지요 물론 공개되어 있는 ‘폼 벨리데이터 (Form Validator)’ 라이브러리가 무수히 많기에 그중에 한넘 골라 쓰면 편하고 쉽게 처리할수도 있습니다 언젠가부터 외국의 서비스들은 javascript로 폼값 체크를 잘 하지 않더군요 facebook 로그인 폼 일단은 form을..
뒤늦게 코멘트를 쓰는거라 뒷북인지 모르겠지만 한가지 첨언을 하자면, 첫번째에서 언급하신 validation 체크는 프론트엔드와 백엔드 모두에서 이중으로 하는 것이 좋습니다. 이런걸 모두 백엔드에서 전담 시키면 반응 속도가 너무 느려져서 사용자 입장에서는 분통터질 일 많이 생기죠. 잘못 입력을 했다면 전송 버튼 누르는 즉시 잘못됐다고 알려주는 쪽이 낫지, 거기서 몇 초씩 기다린 후에 다시 입력하게 하면 사용자 머리에서는 슬슬 열이 끓어오르죠. 물론 서버쪽에서 다시 체크하는건 웹프로그램의 기본 중의 기본이고요. 프론트엔드에서 체크하게 만들었다고 해서 백엔드에서는 체크하지 않을 것이라 지레 짐작하는 것도 편견이 아닐까 생각 됩니다.
흠… 이분은 금지어 밸리데이션 한거를 예를 들었는데요. 그런 목록은 거의 서버에서 하지 않나요? 금지 욕설 목록을 다 html에 쳐 박았다는 건데 말이 안됨.
게임관련 사이트/블로그 링크
rss 구독자가 현재(09.6.5기준) 14056 명이나 되는 이 거대한 파워 블로그는웹2.0에서부터 다양한 관심사와 일상 이야기 등이 아주
간결한 문체로 이해하기 쉽게 쓰였습니다. 어려운 이야기도 쉽게 풀어낼 줄 아는 차니님의 글들을 읽다 보면시간가는 줄 모른다는
말이 바로 이럴때 쓰는 거구나
서버단에서도 처리하고 프론트단에서도 처리하는 게 맞죠.
개인 홈피도 아니고 전부 서버단에서 필터링 하면 자원낭비 입니다.
프론트 단에서 1차 필터링 2차 필터링은 서버에서 하는게 맞습니다.
음…2009년도에 작성하셨던 글이군요. 지나가다….딴지는 아니지만 저도 개발자인데요, 저 위에 ajax라고 하시고 스샷올리신건 json이네요. ajax가 모두 json 방식을 사용하므로 ajax와 js의 json 방식을 착각하신듯하네요 ㅎㅎ json은 플랫폼이나 언어에서 독립적이라 여러 언어에서 두루두루 쓰이죠……. ^^; 참! 여담으로 요즘엔 그렇게 천대받고 별볼일없던 js가 구글의 v8로 탄력받아 이제는 js가 없이는 웹개발이 안되는 상황까지 되어버렸습니다. 하다못해 프론트엔드는 물론이고 백엔드단과 WAS영역까지도 모두 자바스크립트 하나로 끝내는 node.js란 괴물 프레임웍까지 나왔죠. 자바스크립트 잘쓰면 최강의 무기이고, 남발해도 별상관없는 그런 입지까지 되어버렸습니다. 2009년도에 작성하신 글이지만 참으로 격세지감이 느껴지네요. 웹기술은 정말 빨리 발전하는거 같습니다. 그래서 저희같은 사람들은 공부할게 너무 많습니다 ㅜ.ㅡ
obj.responseText를 보시면 Ajax를 쓴것이죠^^ 잘 아시다시피 Ajax는 xmlhttprequest를 쓰는 건데 그 결과를 text와 xml로 받지요. text/json/xml과는 아무 관계가 없습니다.
어쨌든 ajax를 쓸 때 dom hacking이 가능하기에 클라이언트 validation만은 믿어서는 안된다는게 주요 요지입니다. 그건 지금처러 node.js니 해서 백엔드도 다 js를 한다고 해서 달라지는 불변의 진리는 아니에요. 백엔드 개발자들이 아는 많은 보안 이슈들을 ft 개발자도 알아야 합니다^^
그리고 js로 모든 걸 다 해결할 수 있다고 해서 검색엔진이나 장애인 접근성까지 무시할 수 있다는 건 어불성설입니다. 그건 웹이 어떻게 성장했는지 모르는 js 개발자들의 남용일 뿐입니다. HTML5에도 document와 application을 잘 하이브리드하도록 설계된 철학을 가지고 있습니다.
우리 나라는 무슨 기술이든 처음 배울 때 그 기술이 어떤 의미를 갖는지 그 기술이 왜 이렇게 진화되고 있는지 배경 없이 쓰는 방법만 배우는 문제가 있습니다.
동종업계끼리 까지 말자. 네이버는 왜 걸고 넘어지냐..
이런 댓글들은 뭐지? 네이버 알바인가..
본문은 전혀 까는 글이 아닌데..
사실을 늘어놓고 제목 그대로 웹개발 시 자주하는 실수에 대해서 말하고 있는데 오히려 네이버측에서는 감사해야 할 일 아닌가..잘못 개발되어 있는 페이지를 찾아내줬으니 말이야.
좋은 내용 잘 봤습니다. 공감합니다.
일단 핵심 로직, 공격에 활용될 수 있는 로직을 괜히 JS로 노출 할 필요는 없습니다. 만약 노출한다고 의사결정한다고 하더라도 노출하는 것이 어떤 결과로 이어질 수 있는지 인식할 수 있어야 하고, 그에 대한 대안까지 생각할 수 있어야 실력있는 웹개발자겠지요?
아이디, 이메일은 물론이고 고객을 위험에 노출시킬 수 있는 정보를 특별한 이유가 없다면 가리는 것이 맞겠지요. 뭐 이런거 가지고 그러냐고 하시는분 계시는데, 이 글에서 중요하게 말하는 핵심은 위험을 인식하고 예방하려는 태도이지 아이디노출, 로직노출은 그 예로써 설명한 것이라 생각됩니다.
마지막으로 JS 없이는 개발이 힘들어졌다고 하시며 의문을 제기하는 분이 계시는데, 일정부분 이해합니다. 과거에 비해 더없이 그 중요성이 상대적으로 커지고 있지요. 하지만 순수한 웹, 웹의 본질로 되돌아가자는 주장과 목소리 또한 커지고 있지요. 정보격차가 심화되고, 접근 디바이스도 예측못할 만큼 다양해지고 있는 시대에, 누구나 공평하게 정보의 혜택을 받고 참여할 수 있으며.. 시간, 장치, 장소, 플랫폼에 구애받지 않는 웹의 순수한 목적 말입니다.
JS를 통해 더 리치하게 개발하는 것은 웹이라는 뿌리에서 뻗어나온 하나의 가지일 뿐이고, 그 가지는 웹의 본연의 목적과 장점을 일정 정도 해치고 있기 때문에 그 것을 알고 웹개발 최초에 플랫폼 선택시 충분히 고려를 할 수 있어야 겠지요.
그렇게 생각해보면, 2009년에 이런 글을 작성하셨다는 것에 상당히 놀랐고 앞서가고 계시다는 것을 이 글을 통해 느낄 수 있네요..