String SQL Injection
● Test 1 → Your Name’ or 1=1 → 1=1 앞에 ‘가 없는 비정상적인 구조 → ‘ or 1=1 → 이름(Your Name)이 있다고 가정한 상태에서의 입력 → ‘ or = → 이름(Your Name)이 없다고 가정한 상태에서의 입력 SELECT * FROM user_data WHERE last_name = ? No results matched. Try Again. ● Test 2(아래 3가지의 명령어가 같은 명령어이다) → Your Name’ or ‘1=1 → 1=1이 개별 문자열로 인식 → ‘or’1=1 → ‘or’= SELECT * FROM user_data WHERE last_name = ''or'1=1' Not a condition ● Test3 → Your Name’ or ‘1’=’1 → 정상적으로 공격 성공 → ‘or’1’=’1 → ‘or’’=’ SELECT * FROM user_data WHERE last_name = 'YourName' or '1'='1’
→ 왼쪽 목록에 불이 들어온다(상단의 Restart Lesson을 클릭하면 다시 없어진다)
- Stage 1: String SQL Injection 
● 데이터 베이스 수정
Broken Authentication
● 개요 → 취약한 인증과 세션 관리에 대한 내용을 정의 하고 있다 → 인증과 세션 관리와 관련된 애플리케이션 기능은 정확하게 구현되어 있지 않아서 (인증 및 세션 관리 결함을 이용) 공격자가 패스워드, 키 또는 세션 토큰을 해킹하거나 다른 구현 취약점을 공격하여 다른 사용자 계정을 일시적 또는 영구적으로 탈취하는 것을 허용한다
● 실습1 (Insecure login forms) - 안전하지 않은 로그인 양식
→ 개요 : 웹페이지 소스에 로그인 정보를 입력해 놓고 삭제를 하지 않거나 별도의 DB가 없을 때의 공격에 취약한 것을 파악한다 : 실제 서비스를 제공하는 경우에는 이와 같이 개인 정보를 입력하지는 않는다 : 즉 실습을 위한 환경이란 것만 알면 된다 → 실습 환경 : Win 10(테스트)(8080 포트 추가) 192.168.10.129 : CentOS(DNS) (웹 서비스 시스템) 192.168.10.130 : Proxy Server(Burp Suite) → 결과 : 결과를 보면 입력한 개인 정보가 소스에 그대로 노출이 된다 : 따라서 개인 정보(인증)가 저장될 DB가 없기 때문에 인증에 취약할 수 밖에 없다 : DB가 없으면 아래와 같이 html 코드에 아이디 비번이 그대로 노출 된다
→ 참고 사항
: Burp Suite로 홈페이지 정보를 볼 때 먼저 intercept를 켜고 검색을 하면 검색창이 안 뜨는 경우가 있다
만약 안뜨면 intercept를 끄고 웹 페이지를 새로고침 한다
실습 2. Insecure Login Forms(안전하지 않은 로그인 양식)
→ 코드(login1.php) → 결과 : 소스(login.php) 코드를 보면 Client에서 해석할 수 없는 내용으로 구성되어 있다 : HTTP Response를 보면 Client가 볼 수 있는 CSSL로 되어 있는 것을 볼 수 있다 : 즉 SSSL로 구성된 내용은 웹 브라우저에 의해서 해석이 되어 Client에게 제공된다 : 따라서 ID와 비번이 비록 Client가 볼 수 없는 SSSL로 되어 있다고 하더라도 소스에 직접 입력이 되면 보안상 취약할 수 밖에 없다
실습 3. Insecure Login Forms(안전한 로그인 양식)
→ 코드(login2.php) → 결과 : 소스코드에 사용자 개인 정보가 입력되지 않았을 경우 출력 내용에서도 확인할 수가 없다 : 세션과 관련된 내용 (소스 코드 내에 사용자 정보를 기록, 저장한 것)은 입력하지 않는 것이 보안상 꼭 필요하다
실습 4. Sensitive Data Exposure(민감한 데이터 노출) >
→ 코드(login3.php)
→ 개요
: 대부분의 애플리케이션들은 신용카드, 개인 식별 정보 및 정보와 같은 중요한
데이터를 제대로 보호하지 않는다
: 공격자는 신용카드 사기, 신분 도용 또는 다른 범죄를 수행하는 등 약하게 보호된
데이터를 훔치거나 변경할 수가 있다
: 따라서 중요 데이터가 저장 또는 전송 중이거나 브라우저와 교환하는 경우 특별히
주의해야하며 임호화와 같은 보호조치를 취해야한다
→ 결과
: 파라미터의 값이 0에서 1로 수정했을 때 관리자 페이지의 취약점을 발견할 수 있다
: 따라가서 어떤 경우든 관리자 페이지 접속시에는 0으로 해야한다
(잠금 상태로 두어야한다)실습 5(실습 4의 내용을 아래와 같은 시스템 구성으로 작업)
→ Server
: DNS
: Web1 (Linux) with FTP
: Web2 (WS) with IIS
→ Client
: Win 10실습 6. HTTP에서의 Cookies 취약점
→ 코드(login4.php)
→ 결과
: Cookies는 세션관리용(접속상태 유지 목적)으로 많이 사용되고 있다
: 따라서 세션이 유지되는 동안에는 사이트 접속 시 속도 향상에 유리하다
: 그러나 웹 브라우저의 접속 횟수(Hit) 증가에 따라 저장되는 쿠키의 양이 넘쳐나고
그에 따른 사용자 정보도 정보도 저장되기 때문에 가급적 수시로 삭제해줘야 한다
: 웹 브라우저는 사용자에 의해 직접 변경하기 전에는 기본적으로 쿠키 설정이 되어있다
System / Cloud / DevOps Engineer