쓰벌 넘들
그냥남자사람
추천 176
조회 263989
날짜 2021.09.24
|
그을음
추천 59
조회 75509
날짜 2021.09.24
|
허무주의
추천 224
조회 191537
날짜 2021.09.24
|
되팔렘꼴통절단기
추천 20
조회 52154
날짜 2021.09.24
|
S.A.T.8
추천 8
조회 12986
날짜 2021.09.24
|
핵인싸
추천 920
조회 415685
날짜 2021.09.24
|
별빛 단풍잎
추천 5
조회 16810
날짜 2021.09.24
|
찐쿠아
추천 19
조회 28325
날짜 2021.09.24
|
Jade_2
추천 41
조회 181406
날짜 2021.09.24
|
닭도리탕 비싸
추천 26
조회 59193
날짜 2021.09.24
|
유우타군
추천 22
조회 63696
날짜 2021.09.24
|
가챠하느라밥이없어
추천 3
조회 5944
날짜 2021.09.24
|
니미핸드릭스
추천 28
조회 38175
날짜 2021.09.24
|
길가에e름없는꽃
추천 2
조회 8709
날짜 2021.09.24
|
루리웹-2122312666
추천 145
조회 70119
날짜 2021.09.24
|
긴박락
추천 3
조회 9162
날짜 2021.09.24
|
타카가키 카에데
추천 13
조회 17844
날짜 2021.09.24
|
꼬르륵꾸르륵
추천 3
조회 14335
날짜 2021.09.24
|
등대지기 공대생
추천 0
조회 9537
날짜 2021.09.24
|
no.777
추천 6
조회 14129
날짜 2021.09.24
|
루리웹-7309663092
추천 68
조회 61813
날짜 2021.09.24
|
이사령
추천 15
조회 20268
날짜 2021.09.24
|
달걀조아
추천 4
조회 7632
날짜 2021.09.24
|
얼
추천 3
조회 6022
날짜 2021.09.24
|
MK.II
추천 7
조회 12571
날짜 2021.09.24
|
고수달.
추천 3
조회 12091
날짜 2021.09.24
|
『EDEN』
추천 3
조회 5207
날짜 2021.09.24
|
Julia Chang
추천 78
조회 35997
날짜 2021.09.24
|
이게 뭔데 치킨집들아
한마디로 지금 걸어오는 OR '1'='1'(성인남자) 은 손님혹은 가장처럼 보이지만 사실은 도둑이라고 생각하시면됩니다. 그래서 죽일 타이밍을 보고있는것이죠
뭐지 sql injection을 의미하는 것인가?
팩트1 : 저건 암호화랑 하등 상관없다. 위에서 암호화 어쩌고 언급한 유게이들은 죄다 ↗문가 코더들 팩트2 : 한국 사이트는 여전히 저걸로 뚫리는 곳이 있다.
저정도는 너어어어어무 유명해서 당연 필터링 되어있다. 필터링 된거를 변태적으로 우회하는 놈들이 ㅁㅁ쉑들이지
이런 거보면 진로에 대해서 다시 생각되게된다 ㅁㅊㄴ들이 너무많아
저 구문이 뭔가 했는 데 걍 TRUE랑 똑같은 가 보네
요즘은 암호화가 기본이라 저런걸로 뚫리면 ㅄ같이 짰다고 욕먹음
이게 뭔데 치킨집들아
SQL Injection 이라고, 패스워드를 무시하고 관리자 로그인 할 수 있는 웹 해킹 기법
1은 1이니까 항상 참임을 가장해서 패스워드를 뚫는 인젝션 계통임
말넘심
그러면 고기집으로 하자 ^^
뭐지 sql injection을 의미하는 것인가?
왜 깃헙이 껴있지...?
https://m.mkexdev.net/427 대충 이 얘기인가 본데
제3사도
제3사도
이런 거보면 진로에 대해서 다시 생각되게된다 ㅁㅊㄴ들이 너무많아
싱기하다 그럼 이 코드 넣을 수 있으면 어디던 다 뚫린단 소리 아녀
제3사도
저 구문이 뭔가 했는 데 걍 TRUE랑 똑같은 가 보네
보통 패스워드 암호화하고 저장 및 전달하지 않나... 나의 상식이 부족한건가...
그렇겠지. 그래서 저런 거 넣으려고 시도하면 빠꾸먹이는 조치가 필요함.
시노부
저정도는 너어어어어무 유명해서 당연 필터링 되어있다. 필터링 된거를 변태적으로 우회하는 놈들이 ㅁㅁ쉑들이지
80년대부터 2000년 전후까지의 이야기임. 요즘은 암호화되어서 저장하기때문에 저런 식으로 안됨. 암호화하지 않아도 저런 패턴의 비번은 못 넣게 하든가 자체적으로 분리해서 인식되도록 짜여져 있음.
OneTwoDaisy
요즘은 암호화가 기본이라 저런걸로 뚫리면 ㅄ같이 짰다고 욕먹음
치즈처럼?
사실 웬만한것들은 기본적으로 막게끔 되어있는 함수와 문법을 지원함 겁나 옛날버전을 쓴다거나 털려도 상관없는거라 막 짜버리면 모르겠지만...
그래서 쿼리문 실행 전에 필터링 한번 해서 injection검사를 함.
요즘에는 쿼리를 통째로 조립해서 보내는게 아니라 select. * from where userid = ? ? = '1234 'or ''1'='1'' 이런식으로 바인딩해서 보내기 때문에 고대의 유물소리 듣는 기법이예요... ...가 되어야 하는데
분명 이해하기 쉽게 설명해주는거란 느낌은 드는데 뭔 소린지 하나도 모르겠당!
해와달이된 오누이에서 호랑이가 손밀어넣고 엄마다하는거같애
구멍에 딜도넣었는데 임신했다 같은 소린가
요즘에는 쿼리에 대한 입력값을 텍스트로 합치는게 아니라 따로 변수로 처리해서 뭘 입력하던 쿼리 변형이 안생기는 기법을 많이 써요
바인딩 방식 안하고 짜는곳이 요즘도 있나??
있으면 안되는데 아래 있나봐요 ㅋㅋㅋ
한마디로 지금 걸어오는 OR '1'='1'(성인남자) 은 손님혹은 가장처럼 보이지만 사실은 도둑이라고 생각하시면됩니다. 그래서 죽일 타이밍을 보고있는것이죠
SQL 인젝션!
시엘라
프로그래밍하면 대표적인 곳라서? 아 깃헙은 마소에게 먹혔던가?
뭔가 글자 인식돼서 입력되는 순간 ㅈ된다는 느낌은 오는데 정확히 뭔 뜻인지는 모르겠다..
시엘라
자세히 봐요. 드롭테이블이 아니라 드롭 데이타베이스임.
DB삭제 구문
SQLinjection은 이젠 고대의 유물...이 되어야 하건만 왜....
이게 인터넷에 돌아다닌단건 애저녁에 방지됐단 뜻임 그러니깐 유머인거고 ㅋㅋㅋ
orMapper대부분 다 쓰는데 이거면 그냥 다 해결됨. 간단하기도 하고 저게통할려면 sql을 통으로날려야하는데 그런ㅁㅊㄴ은 없을거라 봄..
팩트1 : 저건 암호화랑 하등 상관없다. 위에서 암호화 어쩌고 언급한 유게이들은 죄다 ↗문가 코더들 팩트2 : 한국 사이트는 여전히 저걸로 뚫리는 곳이 있다.
우리학교 컴공 사이트 비밀 질문게시판 저걸로 뚤림 ㅋㅋ 주석처리인 --는 SQL인젝션 감지 되었다고 막히는데 ' or 1 = 1 or ' 는 됨
컴공이라서 저렇게 뚫으라고 한건가 ㅋㅋㅋㅋㅋ
1. ㅇㅇ SQL 인젝션은 암호화랑 별 상관없음. 뭐 실제 DB랑 매핑시켜서 통과시키는 것도 아닌데. 2. 웹 보안과 관련있는 부분이라 사이트 보안 관심없는 곳은 뚫리는데 의외로 많음. 하지만 괜히 했다간 경찰서 정모 할수도 있으니 함부로 시도하지는 말자.
위에 분들이 말하는 암호화는 웹페이지 만들 때 인터넷페이지에서 받은 사용자 비밀번호를 바로 DB랑 매치 시켜 확인하지 않고 그전에 먼저 사용자 비밀번호를 암호화를 거친 다음 그 암호화된 사용자 비밀번호를 디비에 저장된 암호화된 사용자 비밀번호와 매칭 시켜 본다는 이야기 인거 같습니다. 그래서 애시당초 디비에 사용자 비밀번호로 바로 확인되는게 아니라 이미 암호화 되어서 변경된 구절로 디비랑 확인하니까 웹프로그래밍 관점에서 말씀하시는거니 맞는 말이라 생각됩니다.
아뇨 전혀 상관없는 이야깁니다. 애초에 평문과 암호화 데이터는 컴퓨팅 관점에서 동일한 형태인 바이트 데이터고 SQL Injection을 가드하는 루틴과는 레이어가 다르기 때문에 전혀 무관합니다.
아 제 배움이 짧다보니 좀 더 설명해 주실수 있으실가요 ^^;; 저는 단순히 위의 이야기 보고 저걸 말하는건가 싶었는데 좀 더 알고 싶어져서요.
네. 우선 간단히 결론부터 말하자면 저 기초적인 SQL Injection은 저장된 데이터(이 경우 패스워드)와 무관하게 쿼리의 허점을 이용하는 것이기 때문에 데이터가 암호화 되어 있던 말던 상관없습니다. SQL Injection은 패스워드 입력하라고 한 공간에 쿼리의 일부를 넣어서 서버측으로 하여금 앞의 체크 쿼리를 무시하고 항상 true가 되도록 조작하는 방식을 말합니다. 이는 보통 서버측에서 브라우저를 통해 들어온 문자열을 아무 체크도 하지 않고 바로 쿼리로 조합해서 dbms에 던져버리기 때문에 발생하는데요. 크게 3 종류의 방어법이 있습니다. 1. 직접 이스케이프(비쿼리화)한다. 2. PreparedStatement 같은 내장 루틴으로 이스케이프 한다. 3. MyBartis등의 서드파티에 넘겨 알아서 이스케이프 하도록 한다. 사실 3 종류 다 근본적인 방법은 똑같고 누가 하냐만 다릅니다. 다시 암호화로 돌아가자면 결국 비밀번호 데이터 비교 쿼리는 무시되고 마지막의 '1' == '1'로 인해 항상 true를 반환하므로 데이터가 암호화 되었든 안되었든 로그인 할 수 있게 되니 암호화하고는 무관한 거죠. 포인트는 이 쿼리를 어떻게 막느냐입니다.
설명은 Java기준으로 했지만 SQL Injection이 판치던 시절의 perl, php도 마찬가지로 결국 쿼리의 단순 조합을 지양하고, 주어진 데이터가 쿼리로 취급되지 않도록 이스케이프 하는 것이 주된 방어법입니다.
먼저 긴 답변글 감사합니다(_ _) 글을 읽다가 조금 궁금한게 생겼는데 말씀중에 브라우저 문자열을 아무 체크로 하지 않고 바로 쿼리로 조합해서 DBMS로 던져 버린다고 하셨는데 제가 예전에 할 때만 하더라도 바로 DBMS로 던지지 않고 당시에 암호화 시킨다음에 DBMS로 던졌거든요. 그래서 저는 위에 분들도 그걸 이야기 하신거라 생각했구요. 댓글 새로 달고보니 다시 읽어보니 밑에 적으신게 요즘 넘기는 방식을 말하는거 같네요! 답변 감사합니다.
dbms에 쿼리 자체를 암호화 해서 던졌다면 dbms가 로컬에 없고 네트워크 밖에 있는 대형 시스템의 경우에 주로 사용하는데요. 그렇게 하더라도 쿼리가 통째로 암복호화 되는거라서 sql injection은 막을 수 없습니다. 이스케이프를 해줘야 하죠. 암호화와 하등 상관없다는건 이처럼 암복호화가 데이터 또는 쿼리 단위로 수행하는거라 이스케이프 로직과는 계층 자체가 다르다는 말입니다.
근데 일러스트 뭐냐 ㅋㅋ 존내 터졌네 ㅋㅋ
나는 SQL 을 다 까먹었다네
#안됨 $가능
나는 query바로 검증안하고 JPA 에서 조회해 온다음에 엔티티에서 PasswordEncoder로 matching시켜서 검사하니 안전~