[2주차] Burp Suite , 세션/쿠키, SQL Injection, 로그인 로직

** Burp Suite

옛날 Burp Suite에서는 Proxy 설정을 따로 해줘야했다.

IE(Internet Explore)로 들어갈 때나, 옛날 Burp Suite을 사용해야할 경우에는 Burp Suite의 Options 탭에 들어가서 Proxy Listeners를 열어주고 Proxy 설정을 하면 HTTP history에서 데이터를 볼 수 있다.

 

요즘 Burp Suite에서는 Open Browser라는 기능이 있다. 이걸 클릭하면 크로미움이라는 크롬 비슷한 브라우저가 뜬다.

여기서 인터넷을 하면 그 데이터가 자동으로 Burp Suite에 보내진다

 

Proxy 탭의 HTTP history에는 그동안 Burp Suite을 거쳐갔던 모든 데이터가 쌓인다. 그래서 HTTP history를 보고 Web Server의 로직을 파악해야한다.

 

Intercept에 들어가서 Intercept On을 하면 Burp Suite이 흐름을 막을 수 있다 -> 데이터를 조작할 수 있다

 

어떤 패킷에 대해 자세하게 알고싶으면 Repeater로 넘긴다. 패킷을 클릭하고 Ctrl+R -> 해당 Page가 다시 한 번 요청되어 그에 대한 반응을 볼 수 있다

 

** 로그인 과정

① login.php의 아이디와 패스워드 데이터를 Web Server에 전달한다 

② login.php 동적 페이지기 때문에 Web Server는 이 데이터를 WAS에 전달한다 

③ WAS가 로그인 검증을 실행한다 -> DB에서 데이터를 가져와 요청받은 아이디와 패스워드를 증명하고 확인한 다음 로그인이 되면, Web Server는 Client에게 OK한다

④ 이 때 Web Server는 쿠키를 생성해 정보를 담아 HTTP 화면과 함께 Client에게 돌려준다

⑤ 쿠키를 Client가 가지고 있다가 다시 Web Server에 요청할 때 요청과 함께 쿠키를 전달한다

 

Web Server에게 요청을 할 때 쿠키를 전송하는 건 Client다. 즉 쿠키는 Client에서 출발한다.

 

** 쿠키 변조

클라이언트에서 출발한 쿠키 값을 바꾸는 것

쿠키가 Client측 정보이기 때문에 가능

 

Client측 정보를 믿지 않고, 그 정보를 Server측에 저장하는 것이 세션이다 (보안성 ↑)

① 세션에서는 로그인 성공 시 서버 측에 정보를 저장한다

② Client에 유추 불가능한 난수값(Session Id)을 부여하고, 다음에 로그인을 요청할 때 서버는 Cookie를 확인하여 Session Id가 있는지 확인한다

③ Server 측에서는 Session table에 Session Id가 있는지 확인하고, 각 Client의 요청에 대한 응답을 한다

 

정보는 Server측(WAS)에 저장되어 있기 때문에, Client는 세션 테이블의 값을 바꾸지 못한다 

 

쿠키에 Session Id가 들어간 것을 볼 수 있다(php가 만들어준 session id) 

Client가 Server측에 요청할 때 Cookie에 Session Id를 같이 보내므로 Session Id는 Client측 정보이다. 쿠키 데이터 안에는 다른 데이터와 함께 Session Id도 포함되어 있다.

 

** DB

> 데이터를 저장해두는 장소

> DB 안에 여러 Table이 존재한다

> 세로 줄: 컬럼(열)

> 가로 줄: 로우(행)

 

** SQL Injection에서 꼭 알아야 하는 명령어

① select 문 (검색)

select [컬럼 이름] from [테이블 이름] (where [조건문])

 

② insert 문 (데이터 삽입)

insert into [테이블 이름(컬럼1, 컬럼2, .. )] values(데이터1, 데이터2, .. )

 

③ delete 문 (데이터 삭제)

delete from [테이블 이름] (where [조건문])

 

WAS는 SQL 쿼리문을 항상 가지고 있다가 Web Server로부터 정보를 전달받으면 WAS가 이를 적용해 DB에 전달하고 실행한 후, 그 결과를 사용한다. SQL Injection은 이 과정에서 일어난다

 

** 로그인 과정

① 식별

-> 그 사람의 정보를 가져오는 것

-> 식별 정보 : id

-> 식별정보는 primary key로 등록되어있어야 한다 (= 중복된 id가 있으면 안 된다)

 

② 인증

-> 그 사람의 정보가 맞는지 확인하는 것

-> 인증 정보 : 비밀번호, otp 등등 (노출되면 안 되는 정보)

 

** 로그인 로직

가능한 한 모든 케이스의 로그인 페이지를 다 만들어봐야함, 거기서 인증 우회하는 것도 연습, 로직마다 우회하는 법이 다 다르다

① 식별과 인증을 동시에 하는 케이스

sql 질의문 한 번으로 식별과 인증을 동시에 하는 케이스

 

ex)

select * from table where id = '' and pass = '' #2개가 참이어야 하는 논리연산

if(sql 질의 결과 데이터가 존재){
    로그인 성공
} else {
    로그인 실패
}

 

② 식별과 인증을 분리한 케이스

 

ex)

 select pass from table where id = '~' #id가 ~인 비밀번호만 가져와 (식별)

if(DB의 비밀번호 == 사용자가 입력한 비밀번호) {
    로그인 성공
} else {
    로그인 실패
}

근데 두 가지 케이스 모두 보안에 취약하다