Web Application Security

▶ Task 1 : Introduction

우리는 모두 각자의 컴퓨터에서 서로 다른 프로그램을 쓰는데,
프로그램은 컴퓨터에서 동작하면서 컴퓨터의 processing power(처리 능력) and storagy(저장소)를 사용한다.
또한 프로그램을 사용하기 위해선 먼저 "설치"해야 하는데 만약 설치 없이 프로그램을 사용할 수 있다면 어떨까?-?

 

web application은 firefox, safari, chrome과 같은
최신 표준 web browser만 있으면 설치 없이 사용할 수 있는 "프로그램"과 같다. 

 

따라서 프로그램을 설치하는 것 대신,
관련 페이지를 찾아보기만 하면 된다.

web application의 예는 아래와 같다. 

 

 

• weather forest
• money transfer
• web mail
• online shopping, online banking, online office suits
• social media

web application의 개념은 원격 서버에서 실행되는 프로그램이라는 것.

 

여기서 서버란, 

클라이언트에게 서비스를 제공하기 위해 계속해서 동작하는 컴퓨터 시스템을 의미하며

이런 경우, 서버는 web browser에서 접근할 수 있는 특정한 유형의 프로그램을 실행시킨다. 

 

---

online shopping application에 대해 고려해 보자.

▷ web application은 database server로부터 상품과 상품의 세부정보에 대한 데이터를 읽음.

▷ database server는 database에 내용을 작성하고 검색하고 읽는 것을 포함하는 여러 기능을 수행.

▷ database는 조직된 방식으로 정보를 저장하기 위해 사용.
▷ information에는 상품, 고객, 송장 or 명세서와 관련된 정보가 포함됨.

이와 같이 online shopping application을 고려해 봤을 때,

 

 

아래와 같이 하나 이상의 database에 접근할 필요가 있을 것이다. 

• products database : 제품의 이름, 사양, 가격과 같은 제품의 세부내용을 포함하는 database.
• customers database : 이름, 주소, 이메일, 전화 번호와 같이 고객에 관련된 모든 세부 내용을 포함하는 database.
• sales database : 고객마다 구매했던 제품, 결제방식 등에 대한 내용을 포함할 것이라 예상

 

[Suppose]

공격자는 이러한 web application을 해킹하고 customers' database를 도용할 것이다. 

그런 경우, 회사와 고객들을 상당한 피해를 입게 된다. 

 

 

사진을 통해 item을 검색하는 과정을 살펴보자. 

https://tryhackme-images.s3.amazonaws.com/user-uploads/5f04259cf9bf5b57aed2c476/room-content/9efb37af45d16b776ec3d6c6b9235c15.png

STEP1) 사용자는 검색할 상품 이름, 관련된 키워드를 검색 field에 입력. browser는 shopping application에 입력된 키워드를 전달한다. 

STEP2) web application은 전달 받은 키워드를 가지고 product database에서 관련 상품을 찾는다.

STEP3) product database는 web application에게 키워드와 매치되는 결과를 반환한다.

STEP4) web application은 검색 결과를 web page와 같은 형태로 만들어서 사용자에게 전달해준다. 

 

단순히 말해, item을 찾는 과정은

user, application(server), database 간의 상호작용이라 말할 수 있다.

 

user는 단지 web browser만을 이용해서 서비스에 접속하기만 하면,
검색뿐만 아니라 위에서 나열했던 서비스들을 사용할 수 있는 것이다!!

 

 

---

▶ Task 2 : Web Application Security Risks

자, online shop에서 물건을 구매하고 싶다고 가정해 보자.

고객이 web application을 통해 물건을 구매하는 과정에서 웬만하면 거치게 되는 특정 절차는 다음과 같다.

 

https://tryhackme-images.s3.amazonaws.com/user-uploads/5f04259cf9bf5b57aed2c476/room-content/352114ac8da5f156f42aa551701323a2.png

위에 제시된 특정 절차와 관련된 공격에 대해 생각해 보자. 

 

▷ Log in at the website :

공격자는 login page에서 password를 알아내기 위해, tool로 wordlist에 많은 단어를 대조

 

▷ Search for the product :

공격자는 검색어에 코드나 특정 기호를 붙여 시스템 침입을 시도

그들의 목표는 target system에서 반환해서는 안되는 데이터를 반환하게 하거나, 실행해서는 안되는 프로그램을 실행하도록 만드는 것.

 

▷ Provide payment details :

공격자는 결제 세부 사항이 일반 텍스트로 전송되었는지 or 약한 암호화가 사용되었는지 확인

 

---

[Identification and Authentication Failure]

Identification : user를 고유하게 식별하는 기능

Authentication : user가 자신이 주장하는 사람임을 증명하는 기능

 

보통 online shop에서는 user의 신원을 확인하고, 인증해야 시스템을 사용할 수 있다.

하지만 이런 과정에서 다양한 유형의 취약점이 발견될 수 있다.

• 공격자가 로그인에 유효한 credential을 찾기 위해 brute force를 실행하도록 허락
• 사용자가 약한 비밀번호(weak passwd)를 사용할 수 있도록 허용
• 사용자의 비밀번호를 일반 텍스트 형태로 저장 가능

 

 

[Broken Access Control]

Access Control : user들이 자신의 역할 or 업무와 관련된 파일에만 접근할 수 있게 함. 

access control에 관련된 취약점의 예는 다음과 같다. 

• "the principle of the least privilege"를 적용하지 않고 user에게 필요 이상의 접근 권한을 부여.
  (online customer은 아이템의 가격은 볼 수 있어야 하지만, 가격을 변경할 수는 없어야 함)
• 고유한 식별자를 이용하여 다른 사람의 계정을 볼 수 있거나 수정 가능하게.
  (한 은행 고객이 다른 은행의 고객의 트랜젝션을 볼 수 있어서는 안 됨) 
• 인증되지 않은 사용자가 인증이 필요한 페이지를 탐색 가능하게. 
  (그 누구도 로그인 전에는 mail을 볼 수 없음)

 

 

[Injection]

Injection

: user가 악의적인 code를 input의 일부로 주입할 수 있는 web application의 취약점을 뜻한다.

이런 취약점의 원인 중 하나는 user의 input에 대한 적절한 유효성 검사와 정제 과정이 부족하기 때문!

 

 

[Cryptographic Failures]

이번 범주는 암호학과 관련된 내용로, 

Cryptography는 데이터를 암호화하고 복호화하는 과정에 중점을 둔다. 

 

Encryption(암호화)은 평서문을 암호문으로 바꾸는 것을 의미하고, 반대로 

Decryption(복호화)은 암호문을 다시 평서문으로 변환하는 것을 뜻한다.

 

암호문은 secret key를 모르면 데이터를 원상복귀 시킬 수 없기 때문에, key가 없으면 데이터를 읽을 수 없게 된다.

이번 범주와 관련된 예를 간단히 살펴보자.

• HTTPS 대신 HTTP를 사용하여 민감한 데이터를 일반 텍스트 형태로 보낼 경우.
  HTTP는 HTTPS와 달리 secure version이 아니기 때문에 사용자가 보내는 내용을 다른 사람이 확인할 수 있다.
• 약한 암호화 알고리즘에 의존하는 경우.
  13 rotation처럼 단순하고 쉬운 알고리즘은 깨지기 쉽다.
• 암호화 기능으로 기본 or 쉬운 key를 사용하는 경우.
  secret key를 0000 or 1234로 사용한다면 암호화가 쉽게 풀리게 된다.

---

▶ Task 3 : Practical Example of Web Application Security

[find flag]

"view site" 버튼 클릭하면 우측에 browser가 생긴다. 

해당 browser에 띄워진 화면. 

 

다른 session에서는 딱히 볼 게 없고, "Your Activity"를 눌렀을 때 url이 흥미롭게 생겼다.

user_id가 11이라고 하는데, 그럼 1부터 쭉 user가 있는 건가? 싶어서 일일이 입력해 봤다. 

 

해본 결과, 4~6은 user가 존재하지 않았고 id가 1~11인 user 중에서

id = 9인 user만 최근 활동에 대한 기록이 적혀 있었다.

"Revert"라는 버튼이 괜히 누르고 싶게 생겨서 하나 눌러봤는데 아무 일도 일어나지 않아 나머지 버튼도 다 눌렀다

ㅎ.ㅎ

 

버튼을 막 누르다 보면 flag를 찾을 수 있다.