요즘 브라우저가 너무 좋아서 그런건지..
자바스크립트 디버거 띄우고서 조작하면 자바스크립트로만 막은 보안은 그냥 뚫리는군요.
가입 막힌 사이트도 가입하고..
1개만 구입하게 한 상품도 여러개 구입하고..
이거 최소한 HTTPS로 접속한 상태에서는 디버거 못쓰게 하던가
뭐 그런 조치가 필요한거 아닌가 싶네요?
... 자바스크립트는 이제 안믿으렵니다.
요즘 브라우저가 너무 좋아서 그런건지..
자바스크립트 디버거 띄우고서 조작하면 자바스크립트로만 막은 보안은 그냥 뚫리는군요.
가입 막힌 사이트도 가입하고..
1개만 구입하게 한 상품도 여러개 구입하고..
이거 최소한 HTTPS로 접속한 상태에서는 디버거 못쓰게 하던가
뭐 그런 조치가 필요한거 아닌가 싶네요?
... 자바스크립트는 이제 안믿으렵니다.
다 서버쪽에서 처리를 또 하지요.
from CV
from CV
왠만하면 결국 서버에서 다시 검증해서 실제처리는 안됩니다.
웹의 보안 모델은 20년 넘게 다듬어진 결과물이고 상당히 좋은구조입니다.
그걸 잘못 활용하는것과 웹은 또 다른 문제구요.
#CLiOS
그러므로 서버단에서 항상 값을 체크해야죠.
이건 js 안써도 마찬가지입니다.
제가 본문에도 쓰지 않았습니까..
가입 막힌 사이트도 가입되고 1개 구매 제한도 여러개 구매 되더라고..
제목에는 웹 보안이 개판이라고 하셨잖아요. ＊
그러라고 스크립트에 언어적 요소를 넣어준개 아닌데
보안이 개판인게 아니라.. 원래 그걸로 보안하면 안되는거에요...
일반 적인 사용자가 실수로 그렇게 동작시키는걸 방지할뿐이지.. 그걸로 보안체크하면 용도를 잘못쓰는겁니다.
보통 보안쪽에 맨먼스를 주지 않은 사이트들이 글쓴이님말씀대로 그래요 ㅎㅎㅎ
조금이라도 비중을 둔데는 저렇게 허술하게 뚫리지 않습니다.
개발자시고 서버사이드 개념을 아신다면 자바스크립트로 웹보안을 이야기 하지 않으실것같은데요...
웹 관련 리버스 엔지니어링이라던가 sql injection 이라던가 그쪽에 관심을 두심이 맞는것 같습니다.
개발쪽 상황이 문제인거지 js랑은 관계없죠.
백엔드 개발자라면 당연히 클라이언트가 js든 c++이든 들어오는 데이터는 항상 의심해야 하는게 기본이니까요.
그럼에도 불구하고 코드가 오픈되니 좀 떨떠름한건 사실이긴 합니다만.
자바스크립트 디버거 띄우고서 조작하면 자바스크립트로만 막은 보안은 그냥 뚫리는군요.
--> 브라우저가 좋아서 그런게 아니라 원래 자바스크립트 태생이 그런겁니다. 그리고 그걸로 보안한다는 전문가는 아무도 없습니다. 웹프로그래밍 조금 한다고 웹보안 전문가일까요?
가입 막힌 사이트도 가입하고..
1개만 구입하게 한 상품도 여러개 구입하고..
--> 죄송하지만 이 부분은 실정법을 위반하는 범법행위입니다. 좋은 목적이었어도 당사자가 문제삼을 경우에는 처벌을 받을 수 있습니다.
이거 최소한 HTTPS로 접속한 상태에서는 디버거 못쓰게 하던가
뭐 그런 조치가 필요한거 아닌가 싶네요?
... 자바스크립트는 이제 안믿으렵니다.
--> 원래 자바스크립트를 보안용으로 안씁니다. 왜냐하면 서버단에서 체크하는게 크게 자원을 소모하는 일도 아니고 가장 확실한 방법이기 때문입니다. 사용자의 입력값은 모두 의심하는게 당연한겁니다.
하지만 실제론 시간에 쫓겨서든 몰라서 그렇든 아니면 정적 파일 수정만 해서 처리하기
위해서든 그렇게 처리하는 경우가 많고 뚫리는게 현실이잖아요?
실제로 허무하게 두군데가 뚫렸구요.. 저도 gsshop같은 경우엔 뚫릴거라고 별로 생각을
안했거든요. 물론 대단히 중요한 부분이 뚫린건 아니지만 뚫린건 뚫린거죠...
gs샵 소스 보니까 심지어 옛날에 무한도전 달력 처리하던 루틴까지 있던데..
아마 대부분의 처리를 자바스크립트에서 하는게 아닌가 싶던데 말이죠...
자바스크립트만으로 처리하고 결국 구매페이지 마지막까지 갑니다.
웹 보안이 문제가 아니라 해당 사이트만 문제라고 하기엔... 자바스크립트로 보안처리하는
경우를 너무 쉽게 찾을 수 있는게 아닌가 싶네요.
정보통신망 이용촉진 및 정보보호 등에 관한 법률
제48조(정보통신망 침해행위 등의 금지)
① 누구든지 정당한 접근권한 없이 또는 허용된 접근권한을 넘어 정보통신망에 침입하여서는 아니 된다.
② 누구든지 정당한 사유 없이 정보통신시스템, 데이터 또는 프로그램 등을 훼손·멸실·변경·위조하거나 그 운용을 방해할 수 있는 프로그램(이하 "악성프로그램"이라 한다)을 전달 또는 유포하여서는 아니 된다.
③ 누구든지 정보통신망의 안정적 운영을 방해할 목적으로 대량의 신호 또는 데이터를 보내거나 부정한 명령을 처리하도록 하는 등의 방법으로 정보통신망에 장애가 발생하게 하여서는 아니 된다.
브라우저에서 어떻게 동작하든 결과적으로 db에 들어가냐가 문제고
(C++ 게임 클라이언트를 변조하면 그게 보안에 문제가 있는건 아니죠. 서버에서 받고 처리하냐가 문제지)
구매에서 막히면 이는 정상이고 안막히면 그 회사가 제대로 처리를 못한거라고 봐야죠.
오래된 코드가 남아있는건 분명히 문제지만 이벤트 류들은 하루아침에 기획하고 개발하고 서비스 하는 경우가 많아서 코드 관리 제대로 하기가 어렵습니다. 현실적으로.
웹쪽을 해보셨으면 웹 태생이 그렇다는걸 아실테고
많이 안해보셨으면 어플리케이션/서버 개발과는 패러다임이 좀 다르다고 이해하시면 좋겠네요.
js 보안처리가 많이 안된부분은 사실이긴 합니다. 이건 개발자 자질 문제일수도 있고 업계가 신경안써서 그럴수도 있는거구요. js와는 관계가 없습니다. 이게 제가 하고픈 말이네요.
#CLiOS
그렇게 살 이유도 없고...
그리고 자랑은 아니지만 잘못도 아니죠.
그 시점에선 장바구니 항목은 안보고 금액만 보기 때문에 아마 거를 수 없을거라고 봅니다만.
뭣보다 그런 케이스 바이 케이스로 발생하는 항목때문에 카드 결제 부분 코드는 고치지 않을겁니다.
뭐 그래서 자바스크립트로 체크하는거겠지요.
아니 그전에 이제 자바스크립트는 안믿는다뇨..
보안처리하라고 프론트에 쓰는게 아닌데 말이죠.
무슨말씀을 하시는건지 모르겠네요.
gsshop 개발이 개판이다 하면 되는것을 말이죠.
정말 16년차 맞나요?
본인이 쓰신글을 한번 다시 읽어보세요;;;
from CV
실제로 특정 사이트뿐만 아니라 자바스크립트로 보안처리하는 다수의 사이트들을
지칭해서 한 얘기니까 웹 보안이라고 한건데 그게 왜 틀린 말이죠?
자바스크립트로 보안 처리하는 사이트가 gsshop뿐인거 같으세요?
도리어 여기 댓글단 사람들을 이해를 못하겠네요.
자바스크립트로 보안처리하는 사이트가 현실적으로 한둘이 아닌데
자바스크립트로 보안처리하는게 병신이라는둥.. 도리어 현실을 인정하고
어쩔 수 없이 자바스크립트로 보안처리하는 경우가 있는걸 인정하는게
제대로 된 실력있는 실무자라면 당연한 태도같은데요?
현실적으로 트랜잭션이 이뤄지기 전에 모든 데이터에 대해서 다시 서버단에서
유효성을 검증하면 좋겠지만 그럼 대체 쿼리를 몇번을 날려야 합니까?
게다가 중요한 코드를 함부로 수정했다가 버그 생기면 안되는데 웬만하면
그런거 안건드리고 해결하려고 하니까 자바스크립트를 쓰겠죠.
저라도 1회성 이벤트 때문에 추가하는 코드를 카드 결제하는 코드 앞에다가
붙이지는 않습니다.
자바스크립트를 쓸 수 밖에 없는 경우를 모른다는게 더 실력에 문제가
있는거 같네요.
디버거라도 막아야 되는거 아니냐고 한거지.
님이야말로 제 글을 다시 한번 읽어보세요.
자바스크립트를 쓸 수 밖에 없는 경우를 모른다는게 더 실력에 문제가 있는거 같네요.
본인 실력에 더 문제가 있는 겁니다. 자바스크립트로 쓸 수 밖에 없는 경우는 없습니다.
제가 어떤걸 염두에 두고 한 얘기인지 몰라서 지금 그런 얘기 하시나요?
정말 개발자 맘대로 뭐든 할 수 있다고 생각하면 별로 할말 없습니다.
gsshop같은 대형 사이트에서 1회성 이벤트 때문에 카드 결제 하는 서버 사이드
코드 앞에 이벤트 체크 코드를 붙이는 게 정말 가능할 것 같으면 그렇게 생각하세요.
그러다가 버그 생기면 gsshop 이용 고객 전체가 문제가 생기는데 그런걸
누가 쉽게 허락해줍니까? 테스트할만한 충분한 시간이 있는 것도 아니고.
온갖 서버/클라이언트 서비스(게임포함)들이 HTTP를 이용해서도 아무런 문제없이 온갖 종류의 이벤트를 처리합니다.
엉터리 사이트가 많은 건 사실이지만 그건 자바스크립트가 문제라는 증거가 아니라 웹 서비스의 개념도 제대로 없는 엉터리 개발자들이 그만큼 많았다는 증거입니다. 보통은 PM이 엉터리였을거구요.
말씀하신 부분들은 "보안" 이라기엔 좀 많이 나간 부분 같구요, UI상 예외처리 수준으로는 딱히 문제 없어보입니다.
일반적인 사용자의 실수 정도를 막는 용도로의 자바스크립트 사용이라면 괜찮은 정도죠.
하지만 gsshop 같은 경우는 땜빵이 너무 많긴 한가보네요.
자바스크립트만으로 데이터 유효성 체크하는건 위험한 일인데 그렇게 하고 있으니까요.
웹 보안이 개판이다라는 단순한 표현을 가지고 웹 기술 자체나 프로토콜이 개판이다
라는 식으로 해석하는걸 전 이해를 못하겠네요.
뭐 그런 조치가 필요한거 아닌가 싶네요?
자바스크립트만 수정 못하게 하면 될거라고 판단한건 본인인데요?
일반화의 오류를 범하고 있는것도 본인이고요.
반대의견 전부 무시하는것도 본인입니다.
솔직히 좀 무서울 정도로 쉬웠어요.
자바스크립트로 보안을 처리한다 -> 뚫린다
거의 이렇게 느껴질 정도로 말이죠.
디버거 생기기 전에는 이정도는 아니었습니다.
그냥 간단한 경우에는 GET으로 넘기는 파라미터를 바꾸거나
POST로 넘기는건 따로 짜던가 해서 넘기는 식으로 시도해볼 수도
있었지만 gsshop 쇼핑몰 결제처럼 페이지가 3번에 걸쳐서 넘어가고
수없이 많은 파라미터가 넘어가는 상황에서는 자바스크립트 그 자체를
건드리지 못하면 뚫기가 쉽지 않죠.
도리어 HTTPS 믿고서 패킷변조 못하니까 방심하면 역으로 쉽게 뚫리겠죠?
그리고 자꾸 왜 딴 얘기를 하세요? 자바스크립트는 너무 쉽게 뚫리는데 자바스크립트만으로
보안을 처리하는 것에 대해서 말한건데 무슨 패킷변조가 나오고... 내가 언제 웹기술 전체를
부정이라도 했습니까?
디버거로 HTTPS 패킷을 위조하실 수 있습니까?
HTTPS통신한다고 클라이언트단이 해킹에 안전하다고 생각하는게 완전 넌센스입니다.
물론 그렇게 생각할 수도 있는데 우리는 그런 사람을 초보자라고 부릅니다.
존재하고 솔직히 그 숫자가 적지 않을거라고 여겨지는데 왜 자꾸 아무 문제 없다는
식으로 얘기하죠?
그런 사이트가 많은 건 그런 엉터리들이 많거나 그 회사 마인드가 그정도여서 그런것일 뿐입니다.
억지도 적당히 하세요. 1%도 안될거라구요? 왜 현실을 부정하죠?
C로 만들든 JAVA로 만들든 클라이언트단에서 HTTP/HTTPS 리퀘스트 하기전에 파라메터 변조할 수 있는 방법은 무궁무진합니다.
C도 문제고 JAVA도 문제네요?
애초에 자바스크립트에 막혀서 해당 페이지 진입 자체를 못하니까 실제 어떤 파라미터가
넘어가야하는지 모르죠. 결국 어떤 파라미터를 넘기면 될지를 실제 실행시켜 보지 않고 알려면
직전 페이지가 가지고 있던 파라미터들을 가지고 자바스크립트 소스를 분석해서 추측해야 하는데
(요즘은 알기쉽게 action에 페이지 이름 써서 동작하는 경우가 거의 없으니) 굉장한 노가다죠.
요즘처럼 자바스크립트 분량 자체가 어마어마한 시대엔 더더욱 그렇구요.
하지만 자바스크립트 디버거로 체크 자체를 패스할 수 있으면 간단하죠. 비교가 불가능할 정도로
더더욱 쉽습니다.
하지만 주장하시는 부분에 오류도 오류지만 수십년동안 수백만명이상이 개발해온 환경의 히스토리를 무시한 주장은 받아들여질리가 없죠.
첫번째 오류는 HTTPS에서 디버깅을 못하게 할 방법이 없다입니다.
자바스크립트와 HTTPS는 아무런 관련이 없고 브라우저는 아무나 만들면 그만이거든요.
IE든 파이어폭스든 어떤 브라우저가 디버깅을 막아도 제가 만들어서 그냥 쓰면 됩니다.
거창한 브라우저를 만들 필요도 사실 없구요.
두번째 오류는 자바스크립트로는 보안성을 확보할 수 없다는 건 이미 잘 알려진 사실이라는 겁니다.
자바스크립트를 못믿겠다고 하셨는데 그게 정답입니다.
자바스크립트를 믿고 보안작업을 하면 그냥 초보자나 엉터리 개발자입니다.
자바스크립트 디버깅이 주는 생산성이 말씀하신 모든 우려를 수천배 상회하기 때문에 아직도 사용되고 있고 인기가 있는겁니다.
gs홈쇼핑을 예로 드셨는데 gs홈쇼핑 구축된 시점, 유지보수 해오면서 바뀐 부분들 생각해보면 그런 헛점이 여기저기 없는게 이상하겠죠.
그러나 결정적으로 보안이라고 말할 수 있는 부분은 모두 막혀있을 겁니다.
디버깅으로 결제 금액이 속여지는지, 다른 유저 아이디를 탈취할 수 있는지 시도해보시면 아실겁니다(불법입니다)
경력이 오래 되셨으니 이해하셨을거라 믿습니다.
웹은 이제 막 발을 들여 놓으시는 것이니 섣부른 판단은 미뤄두시면 좋을 듯 합니다.
그런데 저도 [주장]을 한건 아닙니다. 제 원문을 다시 읽어봐주세요.
저게 [주장]씩이나 한 글은 아니잖습니까? 그냥 자유게시판답게
지나가는 넋두리처럼 쉽게 한 얘기인데 말이죠..
말씀하신대로 HTTPS에서 디버깅 못하게 하는건 좀 뜬금없는
짓이기도 하고 근본적인 해결책도 아니죠. 다만 현실적으로 다소간의
효과는 기대할 수 있지 않을까 해서 해본 얘기고 애초에 저도
그런 일이 일어날거라고는 기대조차 안하고 하는 얘기기도 합니다.
helloman님을 비롯해 지금 여기 댓글다시는 분들은 모두 개발자인데 개발자는 0 아니면 1이죠.
아닌건 아닌거고 helloman님이 잘못생각하고 있다고 판단되는 부분에 대해 얘기를 하는건데 helloman님께서는 이쪽 업의 특성이 충분히 숙지되지 않은 상태에서 너무 단정적으로 말씀하셔서 이렇게 된 거라고 봅니다.
서로의 영역에 대한 존중이 필요한건데 그게 훼손되는 느낌을 분명히 받았거든요.
이 부분에 대해서는 helloman님이 물러서서 보실 필요가 있다고 생각합니다.
웹보안은 자바스크립트만으로 이루어지지 않다는건 앞서 많이 나왔고
스크립트에서 유효성 체크하고 서버단에서 다시 체크해서 저장하던 튕기던 할겁니다
웹 개발자들이 자바스크립트를 그저 웹뷰에 이벤트를 주기위해 쓰지
말씀하신 보안?을 요구하는 데로 맞춰줄순 없겠네요
그리고 브라우저에서 디버거 못쓰면 자바스크립트 디버깅 못합니다. 일일이 로그 파일 찍어야 하는데 ㅡㅡ
#CLiOS
어차피 서버 클라이언트 구조에서 클라이언트가 해킹되는건 어떤 플랫폼이든 있을 수 있다고 가정해야 하고 실제로도 그렇습니다.
서버단을 제대로 만들지 않는게 문제죠.
그리고 구매제한 같은건 기업입장에서 그게 뚫려도 손해가 아니라고 판단되는 것들에 대해서는 클라이언트단 수정만으로 진행할 수도 있는거구요.
수많은 이벤트를 서버단에서 완벽하게 구현하고 대응하려면 비용이 많이 드니까 그렇게 판단할 수도 있습니다.
아이디/패스워드를 클라이언트단에서 인코딩해서 그걸 서버단에 넣는(실제로 있었던 일)짓이 문제지 구매제한이 뚫리는 건 그리 심각한 문제도 아니구요.
정말로 심각하게 구매제한을 해야하면 서버단에서 검증할거구요.
연차도 연차지만
본인이 쓸글 내용을 본인이 인지하지 못하니
토론이 아니게되네요.
from CV
할말만 했습니다. 자바스크립트로 보안 처리하는 경우가 많은게 현실이다.
하지만 중요한 부분은 아마 뚫리지 않을 것이다.
이런 정도가 전문가의 견해죠. 제가 왜 2번 시도해서 2번 다 성공했을까요?
성공할만한 가능성이 보인 부분을 노렸기 때문이죠.
나라면 이런건 서버에서 체크안한다 싶어서 시도했고 잘 들어맞아서
쉽게 뚫린겁니다. 그래서 설마 이렇게 쉽게 성공할줄은 몰랐던거구요.
정말 방심하는 사람 세상에 많구나 싶어서 쓴 글이고 너무 쉽게 뚫리는건
막자는 의미에서 디버거라도 제한두자고 쓴겁니다. 설사 중요하지 않은 부분이
뚫린다고 해도 이렇게 쉽게 뚫린다면 충분히 문제니까요.
근데 자바스크립트는 아무 문제 없다고 하는 분들은 대체...
독해력이 딸리는건지.. 자바스크립트 자체야 문제가 없겠죠.
보안때문에 자기 자신 IP 얻어오는 것도 막혀서 짜증나는 언어인데...
16년간 개발만 하셨다는 달인입니다.
까놓고 말해드리겠습니다.
요즘 브라우저가 너무 좋아서 그런건지..
자바스크립트 디버거 띄우고서 조작하면 자바스크립트로만 막은 보안은 그냥 뚫리는군요.
가입 막힌 사이트도 가입하고..
1개만 구입하게 한 상품도 여러개 구입하고..
삼을 경우에는 처벌을 받을 수 있습니다.
이거 최소한 HTTPS로 접속한 상태에서는 디버거 못쓰게 하던가
뭐 그런 조치가 필요한거 아닌가 싶네요?
... 자바스크립트는 이제 안믿으렵니다.
웹은 누구나 게시할 수 있고 자유로운 접근이 가능한 공간입니다. 게시된 페이지수 또한 셀 수 없이 많습니다. 그래서 빈틈은 어디에든 존재할 수 있습니다. 아무리 잘 만들어 놓은 사이트라고 모든것을 본인이 할 수 는 없기 때문에 기반 소프트웨어는 가져다 쓸 수 있습니다. 그 기반 소프트웨어로 인해 취약점이 생길 수도 있는 것이죠. 그래서 빈틈을 발견했을때 어떻게 대응하느냐 하는 것이 오히려 더 중요한 보안 요소입니다. 단지 뚫기 어렵게 만드는게 보안 아닙니다. 그런데 본인 글을 읽어 보세요. 취약점 몇개 찾았다고 좋다고 자랑하는 꼴입니다. 그리고 그 취약점이 진짜 취약점인지 확인해 보지도 못했습니다. 왜냐구요? 진짜로 확인하기 위해서는 범법행위가 수반되야 하거든요. 결국 범법행위 또는 무지함 둘 중 하나를 선택해야 하는 상황이죠. 그리고 본인은 웹 전체를 말한 것이 아니라고 하는데 저 또한 그렇습니다. 자바스크립트에 대해 말한건데 본인은 취사선택을 해서 듣고 계시네요? 아니면 정말 모르시는건가요? 글의 목적, 동기, 결과 어느 부분도 수긍 할 수 없는 글인데 무슨 반응을 바라시는 건가요?
님이 수긍을 못하는거야 그럴 수도 있는건데 자꾸 딴지는 걸지마세요.
마음에 안들면 다른 글을 읽으면 되는데 왜 남의 글에 시비를 거나요?
제 글은 아주 단순한 글입니다. 사실 이렇게 댓글을 길게 달면서
말꼬리 잡을 건덕지도 별로 없는 글이에요. 내가 16년차 개발자인게
불만입니까? 별로 할말이 없으니까 남의 연차까지 꼬투리를 잡는데
짜증이 안나게 생겼습니까?
안보이시나요? 제가 권위를 세웠다구요? 저는 초보자라고 무시했던 것에
대해서 반박했을 뿐입니다. 자바스크립트를 모른다구요? 저는 파스칼 언어
컴파일러도 만들어봤던 사람입니다. 자바스크립트 그 자체도 시간만 들이면
언젠가는 만들 수 있어요. 함부로 남을 무시하는게 더 문제 아닐까요?
자바스크립트 디버거가 뭐 처음부터 있던 물건입니까?
원래 자바스크립트는 브라우저에 의해 실행되면서 외부에서
일절 접근이 어려운 환경이었습니다. 그래서 자바스크립트로
보안 처리해도 잘 안뚫렸던거구요. 그러나 디버거가 생기면서
환경이 달라져서 이제 굉장히 쉽게 뚫리게 된거죠.
브라우저에 디버거 생기기 이전으로 돌아가서 한번 자바스크립트
보안 뚫어보세요.
디버거가 없으면 자바스크립트 보안도 그렇게 약하진 않습니다.
물론 결국 자바스크립트 디버깅으로 뚫을 수 있는 류의 버그는
자바스크립트 디버깅이 없어도 뚫으려면 뚫겠지만 들이는 시간과
노력이 전혀 다르죠.
물론 시간은 더 걸리겠지만
아니 예전엔 그렇게 했지만 요즘은 디버거에 js 파일 목록이 좌악 나와서 골라서 볼 수 있더군요.
에고, 말씀하시는것보니 정말 자바스크립트 잘 모르시는 분이네요
예전이 오히려 더욱 자바스크립트 보안이 취약했습니다.
오히려 초창기때는 스크립트로 pc 파일까지 접근 가능했습니다.
디버거가 존재유무가 보안과는 아무상관 없습니다.
디버거는 그냥 개발자 편의를 위한 도구일뿐입니다.
기본적으로 자바스크립트에서는 사용자에게서 받는 인풋의 유효성을 검증하는 형태로 사용합니다. 이걸 보안이라 부르진 않죠. 왜냐하면 말씀하신대로 누구나 분석할수있고 분석이 가능하면 원하는대로 변조가 가능하니까요. 그래서 기본적인 유효성 검사는 클라이언트에서 하고 중요한 보안처리는 서버사이드에서 처리하죠.
자바스크립트를 제대로 공부 하셨는지 의문이네요.
제발 제 선배중 한명은 아니길
클리앙에서 개발 관련 글만 검색해서 보는데 자주 보이는 닉네임이라그동안 아시는 것도 많고 대단하다 생각했는데 이 글로 무너지네요;
웹 보안 개판이라고 말하기엔 오버일지도 모르죠.
하지만 도대체 몇번째 말하는건지 모르겠는데 자바스크립트만으로 유효성 체크하는 경우가
많은게 사실이고 자바스크립트 디버거가 없던 시절에 비해서 디버거로는 매우 쉽게 이런걸
패스할 수 있죠. 매우 쉽다는 말이 모자랄 정도죠.
그래서 쓴 글인데 무슨 서버와 클라이언트 구별을 못한다는둥... 아 진짜 후회됩니다.
뭐 댓글이 너무 많으니 댓글 좀 꼼꼼하게 읽어달라는 말도 무리겠지만...
그것도 모르는 너네들은 내 경력과 실력 가지고 욕하지 말아라 모드로 계속 싸우시니
얘기가 안 끝나죠
예를 들어 엄청나게 큰 기업의 사이트의 회원가입이나 결제 페이지 구조가 매우 단순해서 디버거 없어도 파라메터 수정이 가능하면 그 사이트 보안이 엉망이라고 하시겠습니까?
다른 분들도 계속 얘기하는건데 유효성 검사와 보안은 완전히 다른 영역입니다.
이 부분을 인정하지 않으면 계속 무시당할 수 밖에 없습니다.
개발자가 개발을 논하는데 연차가 무슨 소용입니까?
사실로만 얘기하면 됩니다.
-추가
아예 클라이언트단에서 유효성 검사를 안해도 됩니다.
실제로 그렇게 개발되는 소규모 사이트도 있구요.
서버에서 처리를 당연히 하기 때문이고 그래야만 하니까요.
그게 안된 사이트는 그 사이트 개발자든 PM을 욕하면 됩니다.
한번 잘 생각해 보시기 바랍니다.
분명히 내일이면 모든 그림을 그리실 겁니다.
몰라서 이런 주장을 하시는게 아니라 이쪽의 룰이 익숙치 않으시기 떄문일 뿐입니다.
쉽게 조작이 가능한 사이트들을 전에는 보안이 엉망이라고 했는데 왜 다른 영역이라고
하시는거죠? 저는 그게 잘 이해가 안갑니다.
뭐 어떻게 보면 그건 보안이 아니라 일종의 버그라고 생각할 수도 있을테고
생각하시는 보안은 단순히 의도치 않은 동작을 일으키는 정도가 아니라
사이트를 탈취하거나 마비시키거나 파괴하는 그런 류의 일이 가능한 수준의
것을 말하시는게 아닌가 생각됩니다만 그건 또 보안이란 단어를 너무
축소 해석한게 아닐런지요?
실제로는 조작이 불가능하도록 서버단에서의 검증 처리가 당연히 들어가야 하니까요
최근의 보안이 클라단에서의 정보의 무결성을 믿지 못하기 때문에
서버측에서의 부담을 동반해서라도 체크가 필요한 부분도 있구요
지금 다른 분들이 말씀하시는 보안은 지금 인식하고 계신 것처롬
클라단에서의 무결성을 보장 못받으니
그부뷴은 보안의 영역으로서도 판단 안한다는 거구요
helloman 님은 이렇게 시각적으로 보이는 영역도 처리해 주어야 하는것을 보앙이라고 보시는 거죠
과거에는 서버 리소스가 충분하지 않았으니 대부분의 처리를 클라이언트로 미루려고 했었죠.
그래서 클라이언트단에 중요한 코드들이 많이 올라갔었고 일종의 난독화만 하면 보안이 확보된다는 생각도 하고 그랬죠.
그런 수준에서는 파라메터 노출이 매우 치명적인게 사실입니다.
그런데 이건 보안에 대한 개념 부재와 비용문제로 인한 것이지 당시의 방법이 정상이었던 게 아닙니다.
다른 분도 말씀하셨듯이 현대의 서버/클라이언트 구조에서의 보안은 서버단이 모두 처리합니다.
클라이언트는 어떤게 와도 무조건 뚫리거든요.
안드로이드나 ios도 루팅하면 뚫립니다.
이 경우 중요한 부분에 대해 서버사이드 보안대책이 당연히 있어야 하고 비용(리소스)적인 문제로 보안 레벨을 나누게 됩니다.
치명적이지 않은 문제를 위해 리소스의 상당수를 써야 한다면 그건 엄청난 낭비죠.
이런 경우는 추후 무결성 검사등으로도 걸러낼 수 있구요.
여러가지 방법들이 많은데 클라이언트는 보안의 대상이 아니라고 보시면 됩니다.
물론 클라이언트도 할 수는 있지만 무조건 뚫린다고 보면 됩니다.
디버거 이전에도 자바스크립트 분석이 가능했고, 다만 지금은 디버거로 인해 그 과정이 많이 쉬워졌다는것이지 보안과는 별개인데요
지금은 솔직히 웹서핑하다가 눈에 뭔가 제한이 걸린걸 본 순간 그냥 아무런 부담없이
한번 시도해 볼 수 있을 정도로 쉬워요.. 저도 옛날 사람이라 자바스크립트에 대해서
사실 약간 신뢰가 있었습니다. 왜냐면 옛날엔 디버거가 없었거든요.
gs shop부분도 왜 서버사이드에서 확인을 안하느냐.. 뭐 그런말씀 아니였나요???
계속 자기말만 하시네요
helloman님은 클라이언트에서 코드의 변조를 막는 보호가 있으면 보안에 도움이 될거라고 보고 계시지요.
반면 오늘날 웹 보안 모델은 브라우저의 관리영역(주로 세션관련 메모리)을 제외한 유저 영역은 이미 털렸다고 가정합니다. 따라서 유저영역에 대한 접근성은 보안성의 유무와 아무런 관련이 없어요. 이는 비단 웹뿐만 아니라 온라인 게임이나 다른 클라이언트 서버모델에서도 동일합니다. 이렇게 다들 기본으로 깔고있는 가정을 본인만 부정하시니까 이야기가 어긋나고 있는 것이구요.
client에서 server side로 값 보내면 되는거니
fiddler로도 가능한부분아닌가요?
애초에 자바스크립트 디버깅을 통해 하는거나 그렇게 하는거나
결과는 같습니다. 결국은 특정 페이지에 특정 파라미터를 전달하면
목적을 달성하는거니까요. 애초에 telnet으로 80포트 열어서
타이핑 해서라도 뭐 보낼려고 하면 보낼 수 있는거죠.
다만 그런 식으로 하는건 제약이 있습니다.
우선 애초에 한번도 못들어가본 페이지가 있다면 어떻게 파라미터를
보내야할지 모르죠. wireshark로 패킷 덤프를 뜨고 안뜨고의 문제가
아닙니다. 애초에 패킷 자체가 자바스크립트에 막혀서 발생 자체를
안하잖아요. 그럼 유효한 파라미터 조합을 모르고 그러면 파라미터
내용을 계산해야 합니다. 디버거 없던 시절에는 눈디버깅으로 소스
쫓아서 그걸 계산해야했어요. 생노가다죠.
굉장한 시간과 노력이 필요하고 시행착오도 많이 겪어야 합니다.
뭐 그래도 언젠가 성공은 하겠죠.
다만 이젠 그게 너무 쉬워졌으니 문제라는겁니다.
클라단에서의 조작이 쉽든 아예 까발려져 있든 아무 문제가 아니라고 다들 얘기하시는 거잖아요
왜 자꾸 검증되지 않는 데이터에 대한 주장을 계속 하시는지 모르겠어요
설사 응답을 받더라도 그게 정상 표시가 안된다는겁니다. 제가 텔넷 얘기를 했지만
텔넷으로 80포트 열어서 뭐 어떻게든 원하는 파라미터를 GET과 POST로 보냈다고
치고 응답이 왔을때 이게 웹페이지에 표시가 되야 의미가 있잖아요. 근데 웹브라우저를
통해 정상적으로 접근한게 아니면 응답을 받아도 의미가 없는 경우가 많아요...
이게 문제가 되는게 GET은 몰라도 POST로 보내는 파라미터의 경우에는
웹브라우저 안에선 가짜로 만들어서 보내기가 까다로운거죠. 별도의 HTML 파일을
만들어서 시도해야 하는데 꽤 귀찮습니다.
이게 애초에 정확하게 어떤 파라미터를 보내야 하는지를 모르는 경우와 만나면..
정말 짜증나는거죠. 그냥 귀찮아서 안하고 만다고 생각합니다.
안그런가요? 애초에 서버의 무결성 체크가 없는 케이스만 가정하고 하는 얘기잖아요.
서버에서 잘 체크하는 곳이야 상관없겠죠.
지금 본문 글 자체가 자바스크립트를 쓴 웹보안은 그냥 보안의 무풍지대 로 글을 쓰셨잖아요.
그래서 그런 얘기가 나온거죠
이게 개발을 알고 말고의 문제가 아니라
보안의 영역 기준을 어디까지로 두냐의 논쟁인데
1,"너무 쉽게 뚫리니까 웹(사이트)보안에 문제 있다"
2,"웹보안이 문제있는게 아니라 그 사이트가 문제다"
1,"여기 저기 뚫리던데?"
2,"니가 잘 모르는데 그거 뚫린거 아니다"
1."카드 결제 직전...이래도?"
2,"............거기 아니라고"
문외한이지만 관심있어 댓글 보고 있는데, 이렇게 이해하면 되는건가요?
첫번째 문이 뚫어서
이성은 방어가 약하다 라고 하는 상황? 인것 같네요
아닙니다. 이제 막 숲을 빠져나와 그 성문을 보았는데
이성은 방어가 약하다 라고 하는것 아닐까요?
댓글도 한두개가 아닌데 그런 분들 댓글은 눈에 안보이시나요?
서버 무결성 체크 못하는/안하는 케이스는 꽤 많을겁니다. 그게 현실이에요.
네 사실 많을거예요...
근데 그것도 그것이지만 클라이언트도 믿을게 못되는것도 사실이죠
얼마나 못미더우면... exe를... 5~6개씩 깔고...
공인인증서에 OTP에.... 에효....
현대의 보안에서 서버 무결성 체크를 안하는 경우는 그 사이트가 문제인거지 웹보안이랑은 별개인데요
어느정도 공부한 사람이면 이해하는 부분입니다
댓글 다신 분들은 "웹보안(표준?) 자체는 그리 허술하지 않다"
..약간씩 서로 동문서답 하시느라 100플 넘기신듯해서 적어봤습니다(다들 이과 출신들이라 그러신듯..)
실제로 결제가 이루어진다면(불법행위겠죠)논란은 종식되겠네요
..아.. 내용 보다는 글 제목이 해당 종사자분들께 자극적이군요
내가 네이버 뚫은거 아니냐? 웹이라는게 왜케 보안이 취약하냐? 브라우저를 없애야 되는거 아니냐?
-> 브라우저가 없어도 사이트에 접속하는데 전혀 문제가 없으며 사이트에 접속만 했다고 뚫은건 아니라는거죠.
그렇지만 실제로 결제하려고 할 때 정합성이 맞지 않으면 서버에서 튕길껍니다.
이건 웹 환경 특성이지요~
애초에 자바스크립트 문제가 아닙니다.
사이트 파라메터 조작은 그냥 주소창에 넣으면 그만인 사이트가 널리고 널렸습니다.
굳이 파라메터를 감추지도 않아요.
GET방식으로 파라메터 주절주절 늘어놓는 상업사이트도 엄청나게 많습니다.
그런다고 무슨 문제가 있나요? 전혀 없습니다.
당장 클리앙의 주소창에도 파라메터가 나열되어 있네요.
여기에 파라메터를 적절히 넣어서 열람불가인 게시물을 보려고 했을 때 봐지면 그냥 서버잘못인 겁니다.
자바스크립트고 뭐고 그 이전의 문제라는 겁니다.
서버 보안이 안된건 그 자체가 문제지 그걸 자바스크립트 문제로 얘기할 필요가 없습니다.
저는 이만...
애초에 본문에 이렇게 쓰여있지 않습니까?
자바스크립트로[만] 막은 보안은 그냥 뚫리는군요.
근데 제가 언제 자바스크립트 그 자체를 문제삼았다고 사람들이 이러는지 모르겠습니다.
웹이 뚫렸다는건 웹 서버가 뚫린 거지 자바스크립트가 뚫렸다고 하지 않습니다. 애초에 거긴 보안이 안 들어가는거니까요. 자바스크립트는 유저 가이드 느낌이죠. "숫자만 입력해요!" "100개 이하만 입력해요" 그런데 이거 무시하고 서버로 문자나 1000개를 입력해서 보낼 수 있어요. 애초에 내 로컬에 있는 소스니까요. 자바스크립트 안 타고 http 요청을 직접할 수도 있죠. 그러니 클라이언트 데이터는 믿지 않는겁니다. 그래서 자바스크립트에 보안이 맞지 않는 이야기라고 하는거고요. 필요 없을뿐더러 해봤자 당연히(!) 털리니까요~
파라메터 조작으로 뚫렸다면 그냥 그 웹서버 로직의 보안이 약한겁니다.
애초에 본문에 이렇게 쓰여있지 않습니까?
자바스크립트로[만] 막은 보안은 그냥 뚫리는군요.
근데 제가 언제 자바스크립트 그 자체를 문제삼았다고 사람들이 이러는지 모르겠습니다.
자바스크립트 좀 뚫리는게 웹 보안 개판은 아니다- 라는 논지로
얘기하다보나 얘기가 좀 많이 걷돌았는데.. 나중에라도 한번
찬찬히 읽어보시기 바랍니다. 서로 얼마나 다른 얘기를 했는지를...
뭐 제목 과격하게 다는건 제 습관이라.. 그 부분에 대해선 늦었지만
사과를 해두죠. 새벽 2시에 이 댓글 볼 분이 얼마나 있겠냐만은.
간만에 키보드 파이팅을 했더니 내일 출근이 걱정이군요.
이제와서 댓글로 반박 논지 얘기 한 사람들한테 글도 안읽는 인간들 취급합니까?
제목 과격하게 다는게 습관이시라면 스스로 실수했음을 인정하시고 정정을 하시던지요..
헬로맨님이 쓰시는 제목은 무슨 본문 의도와 다르니 사람들이 알아서 면죄부라도 주어줍니까?
"1개만 구입하게 한 상품도 여러개 구입하고..."
라고 하셨고, 그게 GSShop이라고 댓글에서 명시하시면서 그런 큰 사이트조차 보안이 엉망이라는 식으로 쓰셨는데요.
...그런데 카드결제 직전까지만 가셨고 실제로는 구입하신 적 없다고 하셨으면, 결국 "구입하고"라고 쓰셨지만 구입하신 거 아니잖아요? 다시말하면 GSShop 뚫리지 않은거구요. 뚫리지 않은 보안을 근거로 개판이라고 하시면 무리수죠. (GSShop 입장에서는 명예훼손 감이구요.)
...결국 추측을 근거로 깐 셈인데, 이러면 아무런 설득력이 없죠...
다른 분들이 본문을 제대로 안 읽은 게 아니라, 본인이 본문을, 그리고 제목을 제대로 못 쓰신 거라고 봐야죠.
1. 헬로맨님이 주장하시는 것 사실여부
1-1. 자바스크립트가 디버그로 통한 변조가 너무쉽다 (사실)
1-2. 자바스크립트를 통해서 Gsshop 최소 구매갯수를 초과했다. (사실)
1-3. Gsshop은 구매갯수를 서버단에서 체크안했으므로 문제가있다 (사실)
1-4. Gsshop은 최소구매갯수를 바꾸어 결제에 성공했다 (시도안함)
1-5. Gsshop의 보안체계를 무너뜨렸다 (결제완료안함)
2.기술적인 내용
2-1.자바스크립트 변조가 쉬우니 웹보안은 허약하다 (거짓)
2-2.많은 사이트들이 프론트단에서만 유효성 검사하는 취약점이 있다. (진실)
2-3.자바스크립트 디버그가 발달하면 웹보안이 허약해진다.(거짓)
2-4.웹은 자바스크립트 때문에 보안이 약하다.(거짓)
정리하자면
웹보안은 클라이언트(자바스크립트) 중간 데이터를 다른값으로 바꾸어서 보낼수 있다 여부가 보안상 중요한게 아니라, 서버가 잘못된 값을 인식하지 못하는 경우입니다.
헬로님이 테스트 해본결과 일부값이 서버가 인식은 못했지만 전체적으로 그게 반영(결제)되었는지 체크가 되지 않았고, 결제 되었다고해도 gsshop의 문제이지 웹보안 전체의 취약은 아닙니다. 그리고 gsshop은 프로세스상 마지막에 체크할 가능성이 높구, 실제 많은 사이트 들이 유효성 검사를 안하여 취약점이 있는것도 사실입니다.
하지만, 헬로맨님이 주장하시는 클라이언트 변조와 https 요청을수정해서 보낼수 있다는 것으로 보안을 안좋다고 주장하신다면 HTTP 프로토콜을 잘 이해하시지 못한부분 같네요. HTTP 사용하는 인증 스펙(jwt, oauth) 등을 참고하시면 좋을듯하네요.
국내에서 프론트단에서만 유효성검사체크하는 곳이 많습니다. 그런 사이트가 웹보안적으로 문제가 되는것 맞습니다. 하지만, 자바스크립트 디버그와 자바스크립트(클라이언트) 수정을 통한 http요청이 가능한점이 웹보안의 단점은 아닙니다. ^^
클라이언트 단에서 아무리 잘짜봤자 프록시를 통해 스푸핑 가능합니다.
고로, 클라이언트 단에서 검증하다는 것은 기본적인 보안사항을 적용하지 않은 것과 같습니다.
무슨 개발자이신지 모르겠는데 게임으로 예를 들겠습니다.
자바스크립트 변조 = 클라이언트를 치자면 패킷변조라고 생각하시면 됩니다.
다들 아시다시피 서버입장에서는 클라이언트에 들어오는 값을 100% 믿으면 안됩니다.
들어오는 인자에 대한 검사는 무조건 들어가야 하겠고요
디버거 뜨는건 많은 사람들이 이야기한것 과 같이 정상입니다.
아무래도 분야가 틀리기에 클라이언트 변조 = 보안성 취약으로 판단할 수 있으실거 같은데요
그러기에 많은 웹개발자가 지금도 비지니스 로직이 클라이언트 (자바스크립트) + 서버로
이중으로 들어갑니다.
물론 서버단 검사를 안하는건 까야 제 맛 이겠죠
기타로.... 그리고 초기 자바스크립트는 참 위험했습니다.
브라우져단에서 (ActiveX 없던 시절....) 클라이언트의 파일 리소스를 이리저리 컨트롤 했으니까요...