협업하는 프론트 개발자의 실력을 떠나서 당연히 백엔드 개발자가 갖춰야할 부분이라고 생각함 프론트에서 넘어오는 데이터들은 쉽게 악의적인 조작이 가능하기때문에 꼭 검증과정이 있어야함 근데 현실적으로 대부분의 개발자들이 미흡한 이유가 이런 데이터 검증과정을 넣는부분은 추가 개발시간이 들어가고 개발에 시간을 쏟아도 개발 당시에는 개발한 티가 많이 안나는 부분이라 그런듯 나중에 운영단계에서 문제터지거나 보안 취약사항 검증 이런거 할때나 그런부분이 개발이 잘돼있는지 알수있고 결국 그마저도 개발한 사람한테 따질수 없고 유지보수 하는 사람이 떠맡게 되는 부분
예전에 지인 요청으로 다른 회사 직원들 백엔드 스터디를 3일 정도 도와준 적이 있는데, 다들 프론트엔드 프레임워크로만 개발해오신 분들이라 그런지 "백엔드는 의심병 하나로 개발하는 거다"라는 주제에 대해 거부감을 느끼더라구요. 계속 강조하고 예시도 설명해주니 납득은 하는 거 같았지만 이런 특수성 때문에 백엔드라는 업무에 대해 그닥 흥미를 갖지 못하는 사람들이 몇몇 있었습니다. 당연히 취향 차이겠지만😊
성향차이임. 백엔드는 안정성을 추구하고 리스크를 최소화하는 방안으로 그리고 퍼포먼스의 향상을 락으로 삼는 포지션이라면 프론트는 물론 리스크를 무시해라 이말은 아니지만 상대적으로 리스크 보완 보다는 새로운 기술, 새로운 방식을 즐기고 도입하는걸 좋아해야함. 새로운걸 많이 도입하고 쓸수록 리스크가 커지는건 개발해보면 다 알지만 당연해짐. 그래서 당연히 리스크 방지하고 진취적이고 둘다 잘하면 좋지만 리소스가 한정적일땐 상대적으로 백엔드랑 프론트랑 성향이 나뉘게됨
클라이언트에서 임시저장된값 불러올때 get으로 하던 post로하던 서버로 날리는 fetch는 위변조가 가능하고, 하물며 form validation도 똑같은 schema를 클라이언트와 서버에 모두 깔아주는데, 개인정보에 접근할 수 있는 요청을 클라이언트단 서버단 모두 verify하는 로직을 넣지 않았다는게 충격. 쉽게 말하면 정말 서버측에서 클라이언트로 res내려줄때 최소 if문 하나 안 넣은게 너무 안일하게 생각했네요
변조를 인위적으로 한 URL 코드 자체가 다른 데이터를 DBMS로부터 꺼낼 수 있어서 성공한거라 if문을 사용해도 똑같이 털리기는 하죠 저 부분이 없는 코드를 입력해도 다른 사용자 정보가 뚝딱 나오는게 아니라 url을 통해서 http요청을 저렇게 보낼 수 있다는게 문제니까.. 뉴스에 나온 분이 얘기한 건 아마 URL인코딩을 얘기하는 것 같습니다
지금은 어떨지 모르겠지만 예전에 유명 중대형 사이트들도 URL 바꾸면 DB 다 보이고 화면 페이지 구성 다 바뀌고 error log 출력하듯 상세하게 보이는 걸 조금만 바꿔서 URL 던지고 dns 털어서 서버 FQFN 정보를 획득해서 쉽게 보이던 기억. 아직도 고쳐지지 않은 중대형 쇼핑몰들도 저럴건데 하물며 방송대 뿐만 아니라 다른 대학들도 차이가 없을 것. 외국에서도 알아주고 인정해주는 대학이라서 국립대이기 때문에 크게 부각이 되었을 듯.
비IT기업이 IT 관련 직원 없이 하청으로 프로젝트 진행하면 거의 대부분 이꼴임. 무슨 완제품마냥 다 완성되어서 나올꺼라고 생각하고 최소한의 검수나 확인도 제대로 안하고 서비스하고나서도 방치하는 원청쪽이나, 원청이 IT모른다고 대충대충 만들어서 납품하고 돈타먹는 하청. 그러니 언제라도 터질지 모르는 시한폭탄이 되버림.
영상에서는 무척간단하게 if 문이라고 이야기 했지만 실제로는 상당히 복잡한 과정을 거쳐야 합니다. 가령 성적표는 사용자 정보와 매칭을 시켜 놓어야 하고 회원 조회가 가능한 경우에는 회원 로그인 후 로그인 세션 생성. 성적표 요청이 들어온 id 를 로그인 사용자가 조회 권한이 있는지 체크 후 처리해야합니다. 비회원이라면 본인인증을 거쳐 인증세션을 만들고 동일하게 권한 체크후 데이터를 조회하는 과정이 필요하죠. 즉 프론트엔드에서 요청 값을 무조건 신뢰하는게 아니라 백앤드에서 모든 필터링을 해야 하는 것입니다.
저희 회사랑 계약 맺고 물건 납품하는 소매체인이 있는데, 이 체인 본사의 웹 SCM이 가관이었습니다. 가맹점 정보 조회하면 post응답으로 json데이터가 들어오는데, 가맹점주들의 개인정보, 아이디는 물론 "비밀번호"까지, 그것도 "평문"으로 보내오더라고요. 아마 가맹점 정보 부를 때 그냥 냅다 select * from ... 때려버린 듯합니다. 본사 담당자한테 얘기해줄까말까 하다가 괜히 "그런걸 어케 앏? 님이 악의적으로 해킹한거 아님???"이라고 혹여나 곤란한 상황 초래할까 싶어 그냥 저만 알기로 했습니다. 대체 어떤 기열찐빠 외주업체에게 개발을 맡겼길래...
0:21 귀여운 작은 실수가 아니잖아욬ㅋㅋㅋㅋㅋㅋ
앞으론 웹 사이트 납품할 때 모의해킹 검수 꼭 받으라고 법으로 정해야 할듯. 건축에 감리가 있듯이.
놀랍게도 si도 감리가 있긴 한데 시간과 금액적인 문제로 세밀하게까진 못해보는... ㅠ
@@user-oq1gz9sf2b SI ㅋㅋㅋㅋ 하하하하하청에다 감리가 ng걸면, 바로 다음 수주가 안되니, 그냥 고기방패용으로 쓰여집니다. ㅋㅋㅋㅋㅋ 한국의 건설카르텔과 똑같다고 보면 됨
좋은 생각입니다
그런데 건축 감리도 철근 빼먹는 걸 못(안) 잡아내는 나라에서 개인정보 보안 감리가 과연 효과가 있을지는...😢
ㅋㅋ 있어도..
@@user-NG8Z7WMRAY3rsK1a 하청내리는거도 건설이랑 똑같음
KT는 exit하나를 뺴먹어 전국 통신망이 마비되는 작고 귀여운 실수를 했었죠
덕분에 롯데리아 결제를 계좌이체로 했던 기억이 나네요
변명이라도 예쁘게 했으면 작고 귀엽다며 그냥 넘어갔겠지만 통신사 ㅅ끼들이라 좋게는 안 보였던..
@@choibino9143 그건 맞죠 허허..
아마도 kt가 아니라 kt 하청요
개발자도 사람이고 업무과중 시달리다보면 실수야 나올수있는데 책임만 제발 똑바로, 제대로 졌으면 좋겠음
늘 느끼지만...어려운 주제를 이토록 쉽고 재미있게 설명해주시는 능력이 정말 탁월하신 것 같습니다. 고맙습니다. 👍👍
선생님 채널도 잘 보고 있습니다.
최고다 섹시애플
귀한곳에 귀한분이... 강의 잘보고잇습니다😊
선생님도 대단하세요!!
새삼 대단
기술적인 부분도 좋지만 제작자의 개그 센스가 돋보이네요 ㅋㅋㅋㅋ
옛날에 SI 신입으로 갔을 때 생각나네.. ㄹㅇ 허구한날 대학 사이트 만들었지만 디자인만 조금씩 다르고 스프링으로 찍어내듯이 만들었기 때문에 저 업체가 만든건 지금까지 하나씩은 나사 빠졌다고 생각하면됨ㅋㅋㅋ
이거보니까 저번에 지원했던 회사가 생각나네요.
면접일정 관리 사이트가 따로 있는곳이었는데 url에 id가 있어서 바꿔봤는데 다른 면접자들의 면접일정을 취소할수있던데..ㅋㅋㅋ
와..케이스를 보면서는 바로 답을 알았는데 개발 단계에서 이런 문제를 고려못했을수도 있겠다..싶어서 소름돋았어요... 정신 제대로 차려야지
백엔드 개발자인데
백엔드 개발하면서 프론트랑 같이 일할때 가장명심해야하는건
프론트는 백엔드를 사용하기 편하게하는거지
프론트의 정보를 절대 신뢰해서는 안된다는마인드로 개발합니다
한마디로 나는 개발하고 프론트는 내가 개발하는걸 사용한다는거죠
쉽게말해 서버는 프론트에서 달라는대로 주면 안된다는거
협업하는 프론트 개발자의 실력을 떠나서 당연히 백엔드 개발자가 갖춰야할 부분이라고 생각함 프론트에서 넘어오는 데이터들은 쉽게 악의적인 조작이 가능하기때문에 꼭 검증과정이 있어야함
근데 현실적으로 대부분의 개발자들이 미흡한 이유가 이런 데이터 검증과정을 넣는부분은 추가 개발시간이 들어가고 개발에 시간을 쏟아도 개발 당시에는 개발한 티가 많이 안나는 부분이라 그런듯
나중에 운영단계에서 문제터지거나 보안 취약사항 검증 이런거 할때나 그런부분이 개발이 잘돼있는지 알수있고 결국 그마저도 개발한 사람한테 따질수 없고 유지보수 하는 사람이 떠맡게 되는 부분
@@user-kn3bt4ho5v 악순환 그 자체네요, 대기업에서는 이런 악순환을 자체 업무 프로세스로 교통정리를 잘 해 놓고 웃으면서 개발하지 않을까요? 저는 그쪽 계열이 아니라 모르겠네요;
근데 저거 ㄹㅇ 멍청한 실수 아니냐? 개인정보 저장하면서 입력하는 페이지에서 헤더에 유저 토큰도 안받았다는건데 이게 대한민국 SI 현주소인가..
20년전에 저런식으로 url상에서 내 아이디 위치에 다른사람 아이디 적으면 그사람으로 로그인되는 사이트 본적있는데, 요새도 저런일이 벌어지는군요
예전에 지인 요청으로 다른 회사 직원들 백엔드 스터디를 3일 정도 도와준 적이 있는데, 다들 프론트엔드 프레임워크로만 개발해오신 분들이라 그런지 "백엔드는 의심병 하나로 개발하는 거다"라는 주제에 대해 거부감을 느끼더라구요. 계속 강조하고 예시도 설명해주니 납득은 하는 거 같았지만 이런 특수성 때문에 백엔드라는 업무에 대해 그닥 흥미를 갖지 못하는 사람들이 몇몇 있었습니다. 당연히 취향 차이겠지만😊
누가 직업병을 물어보면 "만의 하나"라고 말합니다. 별의 별 경우를 다 상정해서 개발하다보니 일상생활에서도 영향이 있더군요... 정말 한번 있을까 말까한 경우를 생각해야 하는게 참 힘들긴 합니다.
성향차이임. 백엔드는 안정성을 추구하고 리스크를 최소화하는 방안으로 그리고 퍼포먼스의 향상을 락으로 삼는 포지션이라면 프론트는 물론 리스크를 무시해라 이말은 아니지만 상대적으로 리스크 보완 보다는 새로운 기술, 새로운 방식을 즐기고 도입하는걸 좋아해야함. 새로운걸 많이 도입하고 쓸수록 리스크가 커지는건 개발해보면 다 알지만 당연해짐. 그래서 당연히 리스크 방지하고 진취적이고 둘다 잘하면 좋지만 리소스가 한정적일땐 상대적으로 백엔드랑 프론트랑 성향이 나뉘게됨
이런것도 의심해야해?? 같은 요소 찾는 재미가 쏠쏠한데 취향 차이라니 신기하네요
코딩이라는거 자체가 원래 모든 경우의 수를 고려해야하는데 아무리 프론트여도 했다는게 놀랍네
오늘 원하는 대로 잘 작동하는 if문 하나 만들었다가 입력에 0 집어넣으니 모조리 맛탱이 가는 일 겪었는데, 댓글들이 공감되서 추천눌렀다
결론 : 정신병은 개발에 유리하다.
이런 기본적인걸 안막아놨다는게 신기하네 ㅋㅋ..
형님은 위트가 있어서 좋네요
재밌게 이야기 하시네요🤭ㅎㅎ
ㅋㅋㅋㅋㅋ 미들웨어에 최소한의 장치만 작성해도 이런일이 없을텐데 너무 웃기네요, 인터뷰도 정말 황당하네요, url이라니…
근데 한편으로 이번 뉴스덕분에 간단한 프로젝트라도 이런 사소한 이슈가 생기지 않게 보안에 대해 더 의식하게 되네요 :)
3:13 아니 자연스럽게 개소리하는 게 개웃김ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
능력있는 개발자는 많지만 결국 다들 자기 수준에 맞는 처우를 해주는 기업에만 가죠...
결국 이쪽에 돈쓸생각 없는 기업들 코드는 별 이상한 하청이 만들게되고 꼭 저런 말도안되는 사고를 치는것같아요... 특히 은행이나 공공기관들ㅋㅋ
유용한 영상 감사합니다!
간단한 비밀번호를 유저가 설정하게 해서 그에 맞는 토큰을 부여 하는게 낫지 않을까... url로 잘못접근하면 토큰값 비교하고 접근 불가하는걸로..
외주개발업체쨩! 맛따꾸~
2:42 이거는 정확히는 '내 정보, 내가 요청한 지원서 정보 == 요청자의 지원서 정보의 지원자가 요청자정보와 동일'이겠죠? 그리고 마지막에 의심병에 빵 터졌네요
토큰에서 아이디 뽑아다가 검증은 기본인데
클라이언트들이 하청주면 속편하니까 여기저기 막 뿌리고 업체 검증도 안하고
편한만큼 잃는것도 많은 법
의심증 강박증 반박증 다 있어서 문제 제기하면 막상 관리자가 그건 중요치않다며 일정만 가지고 논함 😂
제목 엄청 잘지었네요. if문 보고 뭔가싶어서 들어왔
오늘 검색하다가 공적 웹사이트에 ssl 보안인증서 설치 안된거 보고, 잠시 저의 눈을 의심했답니다. ㄷㄷㄷ 비개발자로 코딩 배우고 있는데 점점 코딩의 매력에 빠지는걸 보니 이상한 사람이 맞나봐요. ㅎㅎ 좋은 정보 감사합니다.
ssl 은 주기적으로 갱신해야 되는거라 전담 하는 사람 없고 외주주면 대부분 만료 되는거죠 ㅎㅎ..
@@utb3 흐미…안타깝네요. 즐코팅 하세요.
어쩐지..내가 성격 좋고 사람 좋아해서 코딩을 못하는거였구나!
서버: 헛소리하지 마세요
ㅋㅋ "설마.. 그정도로 악의를 가지고 이상한짓을 하겠어?" -> 함
방통대는 예전에 성적확인해서 url 바꿔서 다른사람 성적 열람도 가능한 문제가 있었습니다.
다니시는 분이 직접 보여주고 학교에 제보했다고 하더군요
편집증에 게으름은 최고의 개발자 기벽이지
동의1
여친없는 특징 아닌가
이거 ㅋㅋ 예전에 네이버북스 초창기에 있었음. 다음권 결재 안해도 url바꿔서 보고 대여기간 지난것도 시스템시간 바꿔서 볼 수 있고 10년전인데 지금은 당연히 막혔겠지
코딩애플 목소리를 들으니 마음이 편해진다...
짤 하나하나가 주옥같이 씹덕이네 ㅋㅋㅋㅋ
key 가 될 수 있는 값들 중 값을 sequence 같이 순차적으로 채번되는 항목은 모두 암호화 대상으로 해야합니다. 이걸 모르는 개발자들이 상당히 많아요.
결론 듣고 소름 ㄷㄷㄷ
말투 진짜 넘 좋다
결말까지 완벽하다. 뎨헷!
클라이언트에서 임시저장된값 불러올때 get으로 하던 post로하던 서버로 날리는 fetch는 위변조가 가능하고, 하물며 form validation도 똑같은 schema를 클라이언트와 서버에 모두 깔아주는데,
개인정보에 접근할 수 있는 요청을 클라이언트단 서버단 모두 verify하는 로직을 넣지 않았다는게 충격. 쉽게 말하면 정말 서버측에서 클라이언트로 res내려줄때 최소 if문 하나 안 넣은게 너무 안일하게 생각했네요
0:20
아니 뭘 생각하신거얔ㅋㅋㅋㅋㅋㅋㅋㅋㅋ
2:25 이 영상의 핵심
변조를 인위적으로 한 URL 코드 자체가 다른 데이터를 DBMS로부터 꺼낼 수 있어서 성공한거라 if문을 사용해도 똑같이 털리기는 하죠
저 부분이 없는 코드를 입력해도 다른 사용자 정보가 뚝딱 나오는게 아니라 url을 통해서 http요청을 저렇게 보낼 수 있다는게 문제니까..
뉴스에 나온 분이 얘기한 건 아마 URL인코딩을 얘기하는 것 같습니다
SI쨩 엣큥이냐고ㅋㅋㅋ
원래 하드코딩이 보안이 더 좋긴하죠 ㅋㅋ 뭐 최적화 뭐시기하다가 다 놓침 ㅋㅌ
코드 한 줄 잘못돼서 털린다니 무섭네요...
코드니까요
외주개발운영 맡기는곳 특히 공공기관 오래된 서비스인데 규모가 작다면 털릴곳 많습니다
테스트와 품질보증이 중요한 이윤데 울나라는 그걸 없어도되는것으로 취급하죠
증상은 덤 ㅋㅋㅋ 코딩애플님도? ㅋㅋ
편집왤케웃기냐ㅋㅋㅋㅋㅋ😂
의처증 ㅋㅋㅋ 저는 임베디드라 까딱잘못하면 사람죽일수도있어서 의처증을 달고사네요..
코딩이 절대로 지지 않는 러브 코미디 미쳤다
교수가 뉴스 나와서 저런 소리 했다는게 더 레전드ㅋㅋ
변조(를 통한 악용) 방지 대책이 없었다고 이해하면 되지 꼭 이 악물고 뒤틀리게 이해하려는 새끼 ㅋㅋㅋ
재밌습니당
지금은 어떨지 모르겠지만 예전에 유명 중대형 사이트들도 URL 바꾸면 DB 다 보이고 화면 페이지 구성 다 바뀌고 error log 출력하듯 상세하게 보이는 걸 조금만 바꿔서 URL 던지고 dns 털어서 서버 FQFN 정보를 획득해서 쉽게 보이던 기억.
아직도 고쳐지지 않은 중대형 쇼핑몰들도 저럴건데 하물며 방송대 뿐만 아니라 다른 대학들도 차이가 없을 것.
외국에서도 알아주고 인정해주는 대학이라서 국립대이기 때문에 크게 부각이 되었을 듯.
외국에서도 알아주고 인정해주는 대학…?
지원서 코드를 넘버링으로 하는게 아니라 완전 랜덤하게 uuid 만 잘 활용했어도... 끝에 한두자리 바꾼다고 안나올텐데
정상인과 다른... 사람이.. 천재이거나.. 범죄자이거나...
이상한 사람일수록 잘한다면 코딩애플님은....
방통대 신나게 돌려까는거 개웃김ㅋㅋㅋㅋㅋㅋㅋㅋ
“개방성”
다른곳도아니고 명색이 방통대인데.. 어디 어문대학이 털린것도 아니고 간판값못하는거 개한심함
@@롤케익방통대가 간판값..? 웃고 지나갑니다~
@@ahahwgqye12 븅신 지잡대 출신이라 저게 무슨 학위 때문에 가는 곳인 줄 아나? ㅋㅋㅋㅋ
@@ahahwgqye12방통대 코딩을 학생들이 하는 줄 아는 잼민이들은 웃고 지나가겠지. 아직 고등학생이면 간판이라는 단어가 입결 아웃풋얘기로만 보일테니 이해는 감.
URL 변조 이전에 저거 세션이나 로그인 옛날 방식이지만, 쿠키 점검 기능만 넣어도 피할 수 있는 기능인데. 저걸;;;
3:17 미치신거 아닙니까? ㅋㅋㅋㅋ
개방성 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
군대에서 델리스말고 일반인트라넷에서도 비밀번호 걸려있는 비밀글번호 대충 유추해서 주소창에 적으면 비빌번호 몰라도 볼수있었음
비IT기업이 IT 관련 직원 없이 하청으로 프로젝트 진행하면 거의 대부분 이꼴임.
무슨 완제품마냥 다 완성되어서 나올꺼라고 생각하고 최소한의 검수나 확인도 제대로 안하고 서비스하고나서도 방치하는 원청쪽이나, 원청이 IT모른다고 대충대충 만들어서 납품하고 돈타먹는 하청.
그러니 언제라도 터질지 모르는 시한폭탄이 되버림.
폭탄터지면? 책임져야 할 놈들은 전부 실무자에게 다 떠넘기고 꼬리자르기 ㅋㅋㅋㅋㅋ
개인정보 공유 서비스 ㅋㅋㅋㅋㅋㅋㅋㅋ
개발자가 하란대로 하니 뭐 어찌하겠냐 보안담당자가 신경 써서 봐줘야함
요즘 애플형 때문에 웃엌ㅋㅋㅋㅋ
저건 기본 중의 기본인데;; 어이가 없.... 요즘 대학생이 만들어도 저 정돈 아니지않나..
개발자로서 다른 사이트들 황당한곳 많음
여기처럼 로그인만 하면
다른 사람 정보 다 꺼낼수 있는곳 많음
방통대는 돈내고 다니지만, 대학교 혜택 덕분에 개이득인 곳
유튜브 계속 해주셨음 좋겠다. 정말 영상 스타일이 마음에 든다. 유용한 정보를 얻는 영상은 지루하기 마련이지만, 이 사람의 유튜브의 영상은 매우 흥미롭고 유익하다고 할 수 있다.
혹시 ai신가요?
ㅋㅋㅋㅋㅋㅋㅋㅋ 비꼬는 실력이 세계 최고
뉴스보고 왔는데 이영상도 있었네 ㅋㅋㅋ
풉!!! 마지막은 동의 하기 어렵지만 쫌 까칠하면 잘하는듯~ 매사 비관적 아니 비판적이라고 해야 하나?
오늘 영상도 너무 잘 봤습니다.
올 한해 마무리 잘 하세요!
4:15 영상 막바지에 뼈 때리시면 아파요😢
사이다사건
훠 url점핑이네요. 진단파트로 먹고사는 1인으로써 재밌네요 췌헷
순살자이 마냥 구멍이 숭숭 뚫려 있었구만!
궁금한 게 요청한 유저==요청받은 정보의 유저 확인하려면 어떻게 하나요? id랑 pw도 같이 쿼리로 보내면 되나요?
영상에서는 무척간단하게 if 문이라고 이야기 했지만 실제로는 상당히 복잡한 과정을 거쳐야 합니다. 가령 성적표는 사용자 정보와 매칭을 시켜 놓어야 하고 회원 조회가 가능한 경우에는 회원 로그인 후 로그인 세션 생성. 성적표 요청이 들어온 id 를 로그인 사용자가 조회 권한이 있는지 체크 후 처리해야합니다. 비회원이라면 본인인증을 거쳐 인증세션을 만들고 동일하게 권한 체크후 데이터를 조회하는 과정이 필요하죠. 즉 프론트엔드에서 요청 값을 무조건 신뢰하는게 아니라 백앤드에서 모든 필터링을 해야 하는 것입니다.
엄준식은.. 살아있다...
rrno값이 말 그대로 주민등록번호를 md5로 hashing한거면...
90년대 철근 빼먹기 건축 현상이 20년대 IT업계에서 나타나는군요
4:14 ㅋㅋㅋㅋㅋㅋㅋㅋ
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ개방성 ㅌㅋㅋㅌㅋㅌ
저희 회사랑 계약 맺고 물건 납품하는 소매체인이 있는데, 이 체인 본사의 웹 SCM이 가관이었습니다. 가맹점 정보 조회하면 post응답으로 json데이터가 들어오는데, 가맹점주들의 개인정보, 아이디는 물론 "비밀번호"까지, 그것도 "평문"으로 보내오더라고요. 아마 가맹점 정보 부를 때 그냥 냅다 select * from
... 때려버린 듯합니다.
본사 담당자한테 얘기해줄까말까 하다가 괜히 "그런걸 어케 앏? 님이 악의적으로 해킹한거 아님???"이라고 혹여나 곤란한 상황 초래할까 싶어 그냥 저만 알기로 했습니다.
대체 어떤 기열찐빠 외주업체에게 개발을 맡겼길래...
비번 평문으로 저장하는거 불법입니다 신고하세요
나름 강박과 의심을 항상 가지고 살고 있는데 ... 본인에 대한 믿음도 없어서 너무 피곤함
그래서 코딩애플님이
의처증, 강박증, 의심병 있는
삼위일체 그 자체란 소리죠?
잘 알겠습니다.
처가 있으실까요?
요즘 if 쓰,기 싫어하는 사람들도 은근히 있던데 예외처리는 기본아니냐...
형 애니 봐요??
중간중간 나오는 애니짤 내가 아는게 미치겠다
신통방통 하네 ㅋㅋ
몇몇 SI업체는 뜨끔해야지
개방성 공공성 자율성 드립 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
post로 보내면 안들켰을텐데
보안은 그대로겠지만.
남자는 post요청을 쓰지 않습니다
@@codingapple 그래서 남자가 빨리죽
@@codingapple GET한 청년.
개발자필수의양ㅋㅋㅋ
대입지원하면서 url 바꿔볼 생각은 하지도 않았네
"POST를 써야하는 이유"
이유 돌려까는 거 되게 웃기네 ㅋㅋㅋ
지원서 정보를 요청하는 유저가 지원서 소유자랑 같은 유저인지는 어찌 알아요? 쿠키 정보 같은걸로 비교하나요?
SQL 인젝션이 생각나네요
방통대가 아니라 방송대
전에 유튜브 버튼들 링크때도 따로 뭐 안해놔서 바로 다이아버튼 구매했었던
수상할 정도로 다양한 데헷짤