728x90
728x90
728x90
728x90

SQL injection is a type of attack on web applications that allows attackers to execute malicious SQL statements, usually by exploiting vulnerabilities in the application's input validation mechanisms. This type of attack can be devastating, as it can give the attacker full control over the database and access to sensitive information.

In this blog post, we will explore what SQL injection is, how it works, and what steps you can take to prevent it.

What is SQL Injection?

SQL injection is a type of attack that targets web applications that use SQL databases. The attack is carried out by inserting malicious SQL statements into the application's input fields. These input fields are usually used to gather data from users, such as usernames and passwords, and they are often used to build SQL queries that retrieve or modify data in the database.

When an application is vulnerable to SQL injection, an attacker can use these input fields to inject malicious SQL code into the application's database query. This can allow the attacker to execute arbitrary SQL commands, such as deleting data from the database or stealing sensitive information.

How Does SQL Injection Work?

SQL injection attacks typically exploit vulnerabilities in web applications that use user input to build SQL queries. This can happen when an application fails to properly validate or sanitize user input before using it to construct SQL queries.

For example, let's say a web application has a login page that asks users for their username and password. The application might construct a SQL query that looks like this:

SELECT * FROM users WHERE username='username' AND password='password'

If the application doesn't properly validate the username and password fields, an attacker could insert malicious SQL code into them. For example, the attacker could enter the following as their username:

' OR 1=1 --

This would result in the following SQL query being executed:

SELECT * FROM users WHERE username='' OR 1=1 --' AND password='password'

The "--" at the end of the input is a comment symbol in SQL, which tells the database to ignore anything that comes after it. This means that the attacker's input effectively bypasses the password check, allowing them to log in to the application as any user.

Preventing SQL Injection

Preventing SQL injection requires a multi-layered approach that involves both developers and system administrators. Here are some best practices that can help prevent SQL injection attacks:

  1. Use prepared statements: Prepared statements are a feature of most modern programming languages that allow developers to construct SQL queries in a safe way. With prepared statements, input values are passed as parameters to the query, rather than being concatenated directly into the SQL string. This makes it much harder for attackers to inject malicious code into the query.
  2. Use parameterized queries: Parameterized queries are similar to prepared statements, but they are used in situations where the query is executed multiple times with different input values. Like prepared statements, parameterized queries use placeholders for input values, which are then replaced with actual values when the query is executed.
  3. Validate user input: Validate user input at every point where it is used in the application. This includes input from web forms, query strings, cookies, and other sources.
  4. Sanitize user input: Sanitize user input by removing any characters that could be used to inject SQL code. This includes characters like single quotes, double quotes, and semicolons.
  5. Limit user privileges: Limit the privileges of database users to prevent them from executing arbitrary SQL commands.

Conclusion

SQL injection is a serious threat to web applications that use SQL databases. By exploiting vulnerabilities in the application's input validation mechanisms, attackers can execute malicious SQL code that can lead to data theft, data corruption, and other security issues.

Preventing SQL injection requires a multi-layered approach that involves developers and system administrators. By using prepared statements, parameterized queries, and validating and sanitizing

728x90
728x90

'해킹' 카테고리의 다른 글

SSTI 취약점  (0) 2022.01.11
Cross Site Scripting (XSS)  (0) 2021.12.22
Same Origin Policy & Cross Origin Resource Sharing  (0) 2021.12.20
OWASP top 10 / 2021 업데이트 한글 번역  (0) 2021.11.22
구글 도크 (Feat. 디렉토리 리스팅)  (0) 2021.10.14
728x90
728x90

SSTI(Server Side Template Injection)

SSTI(Server Side Template Injection) 취약점은 서버측의 기본 템플릿 구문을 이용하여 악성 페이로드를 삽입, 실행되면서 생기는 취약점이며 웹 템플릿 엔진마다 사용되는 페이로드가 다릅니다.

 

웹 템플릿이란?

웹 템플릿 엔진은 웹 템플릿과 웹 컨텐츠 정보를 처리하는 목적으로 설계된 소프트웨어를 뜻합니다.

웹 서버를 구축할 때 코드에 자주 보이는 {{ content }}, {% content %} 이러한 형식으로 되어있는 대부분이 템플릿 엔진을 사용하기 위해 작성된 템플릿 구문입니다.

Flask 서버를 구축하여 index.html에 {{ 7*7 }}를 작성하고 render_template 메서드로 index.html 파일을 리턴하면 49라는 결과가 웹 페이지에 나오게되는 것 처럼 Flask에서도 템플릿 엔진을 사용하기 때문에 7*7 구문이 정상적으로 실행이 됩니다.

 

SSTI 취약점을 이용한 템플릿 구분

기본적으로 모든 서버는 제각각 다른 서버와 다른 템플릿을 사용하기 때문에 언어와 템플릿 엔진에 따라 취약점을 발생시키기 위한 페이로드가 달라지게 됩니다.

어떤 템플릿 엔진을 쓰고 있는지 알기 위해서는 하단의 사진 처럼 일일히 페이로드를 삽입하여 구별할 수 있습니다.

만약 에러가 나거나 원하는 대로 작동하지 않으면 밑으로, 잘 작동하면 위로 이동하면서 어떠한 템플릿을 사용하고 있는지 어떠한 페이로드를 사용해야되는지 빠르게 파악할 수 있습니다.

 

Flask.config

기본적으로 Flask의 경우 app.n에 들어가는 대부분의 정보들이 config 클래스에 들어가게 됩니다.

만약 app.secret_key에 중요한 정보를 넣었을 때 {{ config }} 해당 페이로드를 삽입하여 config 정보를 출력하게 만들면 app.secret_key에 들어간 중요한 정보들이 나오게 됩니다.


참고문헌

me2nuk - SSTI(Server Side Template Injection) 취약점이란?

728x90
728x90

'해킹' 카테고리의 다른 글

sql injection  (0) 2023.04.01
Cross Site Scripting (XSS)  (0) 2021.12.22
Same Origin Policy & Cross Origin Resource Sharing  (0) 2021.12.20
OWASP top 10 / 2021 업데이트 한글 번역  (0) 2021.11.22
구글 도크 (Feat. 디렉토리 리스팅)  (0) 2021.10.14
728x90
728x90

Cross Site Scripting (XSS)

XSS는 클라이언트 사이드 취약점 중 하나로, 공격자가 웹 리소스에 악성 스크립트를 삽입해 이용자의 웹 브라우저에서 해당 스크립트를 실행하여 세션 정보를 탈취하고 해당 계정으로 임의의 기능을 수행할 수 있습니다.

 

해당 취약점은 SOP 보안 정책이 등장하면서 서로 다른 오리진에서는 정보를 읽는 행위가 이전에 비해 힘들어졌습니다. 그러나 이를 우회하는 다양한 기술이 소개되면서 XSS 공격은 지속되고 있습니다.

더보기

Cross Site Scripting의 약어는 CSS라고 불리는 것이 옳습니다. 그러나 스타일시트를 정의하는 언어인 CSS와의 중복으로, 혼동되어 사용될 수 있기 때문에 XSS로 명명되었습니다.

 

XSS 종류

Stored XSS : XSS에 사용되는 악성 스크립트가 서버에 저장되고 서버의 응답에 담겨오는 XSS
Reflected XSS : XSS에 사용되는 악성 스크립트가 URL에 삽입되고 서버의 응답에 담겨오는 XSS
DOM-based XSS : XSS에 사용되는 악성 스크립트가 URL Fragment에 삽입되는 XSS
Universal XSS : 클라이언트의 브라우저 혹은 브라우저의 플러그인에서 발생하는 취약점으로 SOP 정책을 우회하는 XSS

 

Stored XSS

대표적으로 게시물과 댓글에 악성 스크립트를 포함해 업로드하는 방식이 있습니다. 게시물은 불특정 다수에게 보여지기 때문에 해당 기능에서 XSS 취약점이 존재할 경우 높은 파급력을 가집니다.

 

Reflected XSS

대표적으로 게시판 서비스에서 작성된 게시물을 조회하기 위한 검색창에서 스크립트를 포함해 검색하는 방식이 있습니다. 이용자가 게시물을 검색하면 서버에서는 검색 결과를 이용자에게 반환합니다. 일부 서비스에서는 검색 결과를 응답에 포함하는데, 검색 문자열에 악성 스크립트가 포함되어 있다면 Reflected XSS가 발생할 수 있습니다.

Reflected XSS는 Stored XSS와는 다르게 URL과 같은 이용자의 요청에 의해 발생합니다. 따라서 공격을 위해서는 타 이용자에게 악성 스크립트가 포함된 링크에 접속하도록 유도해야 합니다. 이용자에게 링크를 직접 전달하는 방법은 악성 스크립트 포함 여부를 이용자가 눈치챌 수 있기 때문에 주로 Click Jacking 또는 Open Redirect 등 다른 취약점과 연계하여 사용합니다.


참고문헌

 

728x90
728x90

'해킹' 카테고리의 다른 글

sql injection  (0) 2023.04.01
SSTI 취약점  (0) 2022.01.11
Same Origin Policy & Cross Origin Resource Sharing  (0) 2021.12.20
OWASP top 10 / 2021 업데이트 한글 번역  (0) 2021.11.22
구글 도크 (Feat. 디렉토리 리스팅)  (0) 2021.10.14
728x90
728x90

Same Origin Policy

한 출처로 로드된 문서 또는 스크립트가 다른 출처의 리소스와 상호 작용을 제한하는 보안 메커니즘

 

쿠키에는 인증 정보가 보관되며, 브라우저 내부에 저장됩니다. 그리고 웹 서비스에 접속할 때 브라우저는 쿠키를 헤더에 포함시켜 요청을 보냅니다. 이 덕분에 우리는 한 번 로그인하면 일정 기간동안 로그인하지 않고 바로 서비스를 사용할 수 있습니다.

 

하지만 이용자가 악의적인 페이지를 접속했을 때, 페이지가 자바스크립트를 사용해 SNS 웹 서비스로 요청을 보낸다면 브라우저는 헤더에 해당 웹 서비스 쿠키를 포함시킬 것이고 페이지는 로그인 된 이용자의 SNS로 응답을 받을 것입니다. 이렇게 되면 해커는 마음대로 페이지 사용자의 SNS에 글을 올리거나, 삭제하고, SNS 메신저를 읽는 것이 가능하게 될 것입니다.

이와 같은 문제를 방지하기 위해 동일 출처 정책, Same Origin Policy (SOP) 보안 메커니즘이 탄생했습니다.

Origin

URL구조

URL 구조에서 프로토콜 (Protocol, Scheme), 호스트 (Host), 포트 (Port)가 같으면 Same Origin

https://caffeine-melon.tistory.com의 경우

Scheme : "https:"

host: "caffeine-melon.tistory.com"
port: "443"

URL 결과 이유
https://caffeine-melon.tistory.com/manage/ Same Origin /manage/          Path만 다름
http://same-origin.com/frame.html Cross Origin "https" != "http"  Scheme 다름
https://cross.same-origin.com Cross Origin caffeine-melon.tistory.com !=
cross.same-origin.com         Host 다름
https://caffeine-melon.tistory.com:1234 Cross Origin 443 != 1234        Port 다름

 

Same Origin Policy은 같은 Origin일 경우에만 리소스를 요청하고 사용할 수 있습니다.


Cross Origin Resource Sharing (CORS)

Origin이 다르더라도 서로 리소스를 공유해야하는 상황이 생기기 마련이다.

예를 들어 수신한 메일의 개수를 메인 페이지에 출력하려면 메인 페이지(https://www.naver.com)에서 메일 서비스(https://mail.naver.com)에 관련된 리소스를 요청해야 한다.

이 때, 두 사이트는 오리진이 다르므로 SOP를 적용받지 않고 리소스를 공유할 방법이 필요합니다.

 

CORS는 HTTP 헤더에 기반하여 Cross Origin 간에 리소스를 공유하는 방법입니다. 발신측에서 CORS 헤더를 설정해 요청하면, 수신측에서 헤더를 구분해 정해진 규칙에 맞게 데이터를 가져갈 수 있도록 설정합니다.


참고문헌

mozilla - Same-origin policy

mozilla - Cross Origin Resource Sharing

728x90
728x90

'해킹' 카테고리의 다른 글

sql injection  (0) 2023.04.01
SSTI 취약점  (0) 2022.01.11
Cross Site Scripting (XSS)  (0) 2021.12.22
OWASP top 10 / 2021 업데이트 한글 번역  (0) 2021.11.22
구글 도크 (Feat. 디렉토리 리스팅)  (0) 2021.10.14
728x90
728x90

OWASP top 10

OWASP(Open Web Application Security Project)는 2001년도에 만들어진 국제 온라인 보안 단체이다.
OWASP 가 진행한 프로젝트 중 가장 유명한 것은 OWASP Top 10 인데, 이는 매 2~3년마다 업데이트되며 웹에서 가장 중요한 보안 취약점을 10개를 정리한 문서이다.

 

2021년에 달라진 점

새로운 카테고리 3개가 생겼고 4개의 카테고리는 범위와 이름이 변경되었으며 몇 개의 카테고리는 통합되었다.

 

TOP 10

01 : Broken Access Control

취약한 접근 제어는 2017년 5위에서 2021년 1위로 중요도가 상승하였다. 접근 제어란 사용자가 자신의 권한을 벗어난 행동을 할 수 없도록 제한하는 것을 말한다. 그 제한이 올바르게 작동하지 않을 때를 취약한 접근 제어라 한다. 취약한 접근 제어는 개인정보 탈취 뿐만 아니라 개인정보를 수정하거나 삭제하는 공격으로 이어질 수 있다.

  • 버그 또는 설계 결함으로 인한 권한 상승
  • CORS의 잘못된 구성으로 인해 신뢰할 수 없거나 허가되지 않은 소스에서 API 액세스 허용
  • 인증이 필요하거나 권한이 있는 페이지 접근 허용


02 : Cryptographic Failures

암호화 오류는 민감한 개인정보를 암호화하지 않거나 취약한 암호화 알고리즘을 사용하는 것을 의미한다.

이 항목은 "민감한 데이터 유출"이였지만 원인보다 결과를 중점으로한 이름이였기에 변경하였다.

  • 중요한 데이터를 일반 텍스트로 저장 또는 전송
  • 오래되었거나 취약한 암호화 알고리즘 사용
  • 서버 인증서 및 신뢰 체인의 유효성을 제대로 검사하지 않음


03 : Injection

주입 공격이란 임의의 쿼리 또는 명령을 실행하여 웹 사이트의 데이터를 변경하거나 데이터 베이스를 조회, 수정, 삭제하는 공격이다.
가장 대표적인 injection 공격은 SQL injection과 사이트 간 스크립팅(XSS) 공격이 있다.

  • 사용자가 입력한 데이터를 검증, 필터링 하지 않음


04 : Insecure Design

안전하지 않은 설계 취약점은 설계와 아키텍처의 결함에 중점을 둔다.

구현의 결함과 다른 것으로 취약한 설계로 잘 구현된 것은 여전히 공격에 취약하다.

소프트 웨어 개발 단계가 계획/분석 -> 설계 -> 구현 -> 검증 -> 배포 이런식으로 흘러간다면

초기 단계(설계)에서 생기는 오류는 중간 단계(구현)에서 보완할 수 없다는 뜻인 듯 합니다.


05 : Security Misconfiguration

취약한 환경설정

  • 응용프로그램의 모든 부분에서 보안 강화 부족
  • 클라우드 서비스에 대한 사용 권한이 잘못 구성됨
  • 포트, 서비스, 페이지, 계정 또는 권한과 같은 불필요한 기능 허용 또는 설치
  • 기본 계정/암호가 사용 가능 또는 변경되지 않음
  • 사용자에게 표시되는 오류 메시지에 스택 추적 또는 기타 중요한 정보가 포함됨
  • 최신 보안 기능이 활성화 또는 구현되지 않음
  • 소프트웨어가 최신 버전이 아님

 

06 : Vulnerable and Outdated Components

취약하거나 오래된 구성요소 사용

  • 사용하는 클라이언트측 및 서버측 구성 요소의 버전을 모를 경우
  • 소프트웨어가 취약하거나, 지원되지 않거나, 최신 버전이 아닌 경우
  • 개발자가 업데이트 또는 패치된 라이브러리의 호환성 테스트를 수행하지 않는 경우
  • 구성 요소의 구성이 안전하지 않은 경우


07 : Identification and Authentication Failures

식별 및 인증 오류

  • 자동화된 공격으로부터 보호되지 않음
  • 무차별 공격 허용
  • 기본 암호, 취약하거나 잘 알려진 암호 사용 허용
  • 다요소 인증을 사용하지 않거나 유효하지 않음
  • URL에서 식별된 세션 노출
  • 로그인 후 식별된 세션 재사용
  • 로그아웃 또는 비활성 상태일 때 사용자 세션 및 인증 토큰이 제대로 무효화되지 않음


08 : Software and Data Integrity Failures

소프트웨어 및 데이터 무결성 오류는 무결성이 검증되지 않은 소프트웨어 업데이트, 중요 데이터 및 CI/CD 취약성과 관련된다.


09 : Security Logging and Monitoring Failures

보안 로깅 및 모니터링 오류는 "충분하지 않은 로깅과 모니터링"에서 더 많은 유형의 보안 취약점을 포함하도록 확장되었다.

  • 로그인, 실패한 로그인 및 기타 유형의 이벤트가 기록되지 않음
  • 경고 및 오류로 인해 메시지가 생성되지 않거나 명확하지 않음
  • API 및 응용 프로그램 로그에서 의심스러운 작업을 검사하지 않음
  • 로그만 로컬로 저장하는 경우
  • 응용 프로그램을 실시간으로 공격을 탐지 또는 경고할 수 없음

 

10 : Server-Side Request Forgery

SSRF는 사용자가 요청한 URL의 유효성을 검사하지 않을 때 발생한다. 이를 통해 공격자는 방화벽, VPN 또는 다른 유형에 의해 보호되더라도 조작된 요청을 예기치 않은 대상에게 전송하도록 강제할 수 있다.


참고문헌

OWASP TOP 10 공식문서

crashtest-security : OWASP TOP 10 2021 – THE ULTIMATE VULNERABILITY GUIDE

728x90
728x90

'해킹' 카테고리의 다른 글

sql injection  (0) 2023.04.01
SSTI 취약점  (0) 2022.01.11
Cross Site Scripting (XSS)  (0) 2021.12.22
Same Origin Policy & Cross Origin Resource Sharing  (0) 2021.12.20
구글 도크 (Feat. 디렉토리 리스팅)  (0) 2021.10.14
728x90
728x90

구글 도크

구글의 검색 문법을 통한 해킹을 Google Dork 또는 Google Hacking 이라고 함

문법 내용 사용법
inurl 검색어가 있는 URL을 검색한다 inurl:melon
intitle 검색어가 있는 타이틀을 검색한다 intitle:admin
intext 검색어가 있는 본문을 검색한다 intext:root
site 해당 사이트에서만 검색한다 site:google.com
filetype 해당 확장자를 가진 파일을 찾는다 filetype:pdf

"covid" intitle:conspiracy site:cnn.com

"cnn.com"사이트에서 "conspiracy"을 타이틀로 가진 "covid" 검색

여기까지는 해킹이라고 하기엔...


feat. 디렉토리 리스팅

서버 설정에서 발생하는 취약점으로 브라우징하는 모든 파일들을 보여줌

 

url이 다음과 같을 때 production/login.php를 지우고

~~/admin까지 입력할 경우 하위 디렉토리파일들을 출력한다

 

구글 도크를 이용한 디렉토리 리스팅

url에 admin을 포함한 "index of"를 검색 (index of -> 디렉토리 리스팅을 위한 검색어)


참고문헌

시큐리티 월드 보안뉴스 - 해커들은 왜 구글 검색에 집착하나?

바다향기 웹 서버 디렉토리 리스팅 취약점

구글 검색을 이용한 해킹 방어.pdf

리틴 Blog 디렉토리 리스팅

728x90
728x90

'해킹' 카테고리의 다른 글

sql injection  (0) 2023.04.01
SSTI 취약점  (0) 2022.01.11
Cross Site Scripting (XSS)  (0) 2021.12.22
Same Origin Policy & Cross Origin Resource Sharing  (0) 2021.12.20
OWASP top 10 / 2021 업데이트 한글 번역  (0) 2021.11.22
728x90
728x90