보안 테스트-퀵 가이드

보안 테스트는 웹에서 악의적 인 활동으로부터 시스템을 보호하는 데 매우 중요합니다.

보안 테스트 란 무엇입니까?

보안 테스트는 정보 시스템이 데이터를 보호하고 의도 한대로 기능을 유지하는지 확인하는 테스트 기술입니다. 보안 테스트는 시스템의 완전한 보안을 보장하지 않지만 테스트 프로세스의 일부로 보안 테스트를 포함하는 것이 중요합니다.

보안 테스트는 안전한 환경을 제공하기 위해 다음 6 가지 조치를 취합니다.

Confidentiality − 의도하지 않은 수신자에게 정보가 공개되지 않도록 보호합니다.
Integrity − 발신자로부터 원하는 수신자에게 정확하고 정확한 원하는 정보를 전송할 수 있습니다.
Authentication − 사용자의 신원을 확인하고 확인합니다.
Authorization − 사용자 및 리소스에 대한 접근 권한을 지정합니다.
Availability − 요구 사항에 대한 정보의 준비를 보장합니다.
Non-repudiation − 발신자 또는 수신자가 메시지를 보내거나 받았음을 거부하지 않도록합니다.

예

웹 기반 애플리케이션에서 보안 결함을 발견하려면 복잡한 단계와 창의적인 사고가 필요합니다. 때때로 간단한 테스트로 가장 심각한 보안 위험이 노출 될 수 있습니다. 모든 웹 애플리케이션에서이 매우 기본적인 테스트를 시도 할 수 있습니다.

유효한 자격 증명을 사용하여 웹 애플리케이션에 로그인합니다.
웹 애플리케이션에서 로그 아웃하십시오.
브라우저의 뒤로 버튼을 클릭합니다.
다시 로그인하라는 메시지가 표시되는지 또는 로그인 한 페이지로 다시 돌아갈 수 있는지 확인합니다.

보안 테스트는 실제적인 방식으로 보안 결함을 발견하는 시스템에 대한 통제 된 공격으로 볼 수 있습니다. 목표는 IT 시스템의 현재 상태를 평가하는 것입니다. 그것은 또한 알려져 있습니다penetration test 또는 더 대중적으로 ethical hacking.

침투 테스트는 단계별로 수행되며이 장에서는 전체 프로세스에 대해 설명합니다. 공격을 재현하는 데 필요한 모든 단계를 쉽게 사용할 수 있도록 각 단계에서 적절한 문서를 작성해야합니다. 이 문서는 침투 테스트가 끝날 때 고객이받는 세부 보고서의 기초로도 사용됩니다.

침투 테스트 – 워크 플로

침투 테스트에는 네 가지 주요 단계가 포함됩니다.

발 인쇄
Scanning
Enumeration
Exploitation

이 네 단계는 일반 SDLC와 함께 진행되는 여러 번 반복됩니다.

악성 소프트웨어 (멀웨어)는 공격자 / 멀웨어 생성자에게 시스템의 일부 또는 전체 제어 권한을 부여하는 소프트웨어입니다.

악성 코드

다양한 형태의 맬웨어가 아래에 나열되어 있습니다.

Virus− 바이러스는 자신의 복사본을 만들어 다른 컴퓨터 프로그램, 데이터 파일 또는 하드 디스크의 부트 섹터에 이러한 복사본을 삽입하는 프로그램입니다. 복제가 성공하면 바이러스는 감염된 호스트에 하드 디스크 공간이나 CPU 시간을 훔치는 등 유해한 활동을 유발합니다.
Worm − 웜은 경로에있는 각 컴퓨터의 메모리에 자신의 복사본을 남기는 악성 코드 유형입니다.
Trojan − 트로이 목마는 악성 코드가 포함 된자가 복제가 아닌 유형의 멀웨어로, 실행시 데이터 손실 또는 도난 또는 시스템 손상 가능성이 있습니다.
Adware− 프리웨어 또는 피치웨어로도 알려진 애드웨어는 게임, 데스크톱 도구 모음 및 유틸리티에 대한 상업적 광고가 포함 된 무료 컴퓨터 소프트웨어입니다. 웹 기반 응용 프로그램이며 웹 브라우저 데이터를 수집하여 광고, 특히 팝업을 대상으로합니다.
Spyware− 스파이웨어는 해커가 사용자의 컴퓨터에서 중요한 정보를 얻을 수 있도록 사용자를 익명으로 모니터링하는 침입 소프트웨어입니다. 스파이웨어는 무료 온라인 소프트웨어 다운로드 또는 사용자가 클릭하는 링크에 자주 첨부되는 사용자 및 응용 프로그램 취약성을 악용합니다.
Rootkit − 루트킷은 해커가 도난당한 암호를 통해 설치된 컴퓨터 / 네트워크에 대한 관리자 수준의 액세스 권한을 얻거나 피해자가 알지 못하는 사이에 시스템 취약성을 악용하는 데 사용하는 소프트웨어입니다.

예방 조치

시스템에 멀웨어가 존재하지 않도록 다음 조치를 취할 수 있습니다.

패치 / 업데이트를 통해 운영 체제와 애플리케이션이 최신 상태인지 확인하십시오.
이상한 이메일, 특히 첨부 파일이있는 이메일을 열지 마십시오.
인터넷에서 다운로드 할 때는 항상 무엇을 설치했는지 확인하십시오. 확인을 클릭하여 팝업 창을 닫지 마십시오. 애플리케이션을 설치하기 전에 게시자를 확인하십시오.
안티 바이러스 소프트웨어를 설치합니다.
바이러스 백신 프로그램을 정기적으로 검사하고 업데이트하십시오.
방화벽을 설치하십시오.
항상 브라우저와 애플리케이션에서 제공하는 보안 기능을 활성화하고 사용하십시오.

맬웨어 방지 소프트웨어

다음 소프트웨어는 시스템에서 맬웨어를 제거하는 데 도움이됩니다.

Microsoft 보안 기초
Microsoft Windows Defender
AVG 인터넷 보안
Spybot-검색 및 파괴
Avast! 개인용 홈 에디션
Panda 인터넷 보안
Mac OS 및 Mac OS X 용 MacScan

프로토콜을 이해하는 것은 보안 테스트를 잘 이해하는 데 매우 중요합니다. 웹 서버와 클라이언트 간의 패킷 데이터를 가로 챌 때 프로토콜의 중요성을 인식 할 수 있습니다.

HTTP 프로토콜

HTTP (Hypertext Transfer Protocol)는 분산 된 협업 하이퍼 미디어 정보 시스템을위한 애플리케이션 수준 프로토콜입니다. 이것은 1990 년 이후 World Wide Web을위한 데이터 통신의 기초입니다. HTTP는 요청 메서드, 오류 코드 및 헤더의 확장을 사용하여 다른 목적으로 사용할 수있는 일반 및 상태 비 저장 프로토콜입니다.

기본적으로 HTTP는 TCP / IP 기반 통신 프로토콜로 HTML 파일, 이미지 파일, 쿼리 결과 등의 데이터를 웹을 통해 전달하는 데 사용됩니다. 컴퓨터가 서로 통신 할 수있는 표준화 된 방법을 제공합니다. HTTP 사양은 클라이언트의 요청 된 데이터가 서버로 전송되는 방법과 서버가 이러한 요청에 응답하는 방법을 지정합니다.

기본 기능

HTTP를 간단하면서도 강력한 프로토콜로 만드는 세 가지 기본 기능이 있습니다.

HTTP is connectionless− HTTP 클라이언트, 즉 브라우저가 HTTP 요청을 시작합니다. 요청을 한 후 클라이언트는 서버에서 연결을 끊고 응답을 기다립니다. 서버는 요청을 처리하고 클라이언트와의 연결을 다시 설정하여 응답을 다시 보냅니다.
HTTP is media independent− 클라이언트와 서버가 데이터 내용을 처리하는 방법을 알고있는 한 모든 유형의 데이터를 HTTP로 전송할 수 있습니다. 이는 클라이언트와 서버가 적절한 MIME 유형을 사용하여 컨텐츠 유형을 지정하는 데 필요합니다.
HTTP is stateless− HTTP는 비 연결이며 이는 HTTP가 상태 비 저장 프로토콜이라는 직접적인 결과입니다. 서버와 클라이언트는 현재 요청 중에 만 서로를 인식합니다. 그 후 두 사람은 서로를 잊는다. 프로토콜의 이러한 특성으로 인해 클라이언트와 브라우저는 웹 페이지에서 서로 다른 요청간에 정보를 유지할 수 없습니다.

HTTP / 1.0은 각 요청 / 응답 교환에 대해 새로운 연결을 사용하는 반면 HTTP / 1.1 연결은 하나 이상의 요청 / 응답 교환에 사용될 수 있습니다.

건축물

다음 다이어그램은 웹 애플리케이션의 매우 기본적인 아키텍처를 보여주고 HTTP가 어디에 있는지 보여줍니다.

HTTP 프로토콜은 웹 브라우저, 로봇, 검색 엔진 등이 HTTP 클라이언트 역할을하고 웹 서버가 서버 역할을하는 클라이언트 / 서버 아키텍처를 기반으로하는 요청 / 응답 프로토콜입니다.

Client − HTTP 클라이언트는 요청 방법, URI 및 프로토콜 버전의 형태로 서버에 요청을 보낸 다음 TCP / IP 연결을 통해 요청 수정 자, 클라이언트 정보 및 가능한 본문 내용을 포함하는 MIME 유사 메시지를 보냅니다.
Server − HTTP 서버는 메시지의 프로토콜 버전과 성공 또는 오류 코드를 포함한 상태 표시 줄로 응답 한 다음 서버 정보, 엔티티 메타 정보 및 가능한 엔티티 본문 내용을 포함하는 MIME 유사 메시지가 이어집니다.

HTTP – 단점

HTTP는 완전히 보안 된 프로토콜이 아닙니다.
HTTP는 통신을위한 기본 포트로 포트 80을 사용합니다.
HTTP는 애플리케이션 계층에서 작동합니다. 데이터 전송을 위해 여러 연결을 만들어야하므로 관리 오버 헤드가 증가합니다.
HTTP 사용에는 암호화 / 디지털 인증서가 필요하지 않습니다.

HTTP 프로토콜 세부 정보

HTTP 프로토콜을 자세히 이해하려면 아래 링크를 각각 클릭하십시오.

HTTP Parameters
HTTP Messages
HTTP Requests
HTTP Responses
HTTP Methods
HTTP Status Codes
HTTP Header Fields
HTTP Security

HTTPS (Secure Socket Layer를 통한 하이퍼 텍스트 전송 프로토콜) 또는 SSL을 통한 HTTP는 Netscape에서 개발 한 웹 프로토콜입니다. 프로토콜은 아니지만 SSL / TLS (Secure Socket Layer / Transport Layer Security) 위에 HTTP를 계층화 한 결과입니다.

간단히 말해 HTTPS = HTTP + SSL

HTTPS는 언제 필요합니까?

탐색 할 때 일반적으로 HTTP 프로토콜을 사용하여 정보를 보내고받습니다. 따라서 이것은 누구나 우리 컴퓨터와 웹 서버 간의 대화를 도청하게 만듭니다. 보안이 필요한 민감한 정보를 교환하고 무단 액세스를 방지해야하는 경우가 많습니다.

다음 시나리오에서 사용되는 Https 프로토콜-

은행 웹 사이트
지불 게이트웨이
쇼핑 웹 사이트
모든 로그인 페이지
이메일 앱

HTTPS의 기본 작업

HTTPS 프로토콜의 서버에는 공개 키와 서명 된 인증서가 필요합니다.
https : // 페이지에 대한 클라이언트 요청
https 연결을 사용할 때 서버는 웹 서버가 지원하는 암호화 방법 목록을 제공하여 초기 연결에 응답합니다.
이에 대한 응답으로 클라이언트는 연결 방법을 선택하고 클라이언트와 서버는 인증서를 교환하여 ID를 인증합니다.
이 작업이 완료되면 웹 서버와 클라이언트 모두 동일한 키를 사용하고 연결이 닫혔는지 확인한 후 암호화 된 정보를 교환합니다.
https 연결을 호스팅하려면 서버에 키 소유자의 신원 확인과 함께 키 정보를 포함하는 공개 키 인증서가 있어야합니다.
거의 모든 인증서는 타사에 의해 확인되므로 클라이언트는 키가 항상 안전하다는 것을 확신 할 수 있습니다.

인코딩 및 디코딩이란 무엇입니까?

인코딩은 문자, 숫자 및 기타 특수 문자와 같은 일련의 문자를 효율적인 전송을 위해 특수한 형식에 넣는 프로세스입니다.

디코딩은 인코딩 된 형식을 원래 문자 시퀀스로 다시 변환하는 프로세스입니다. 우리가 일반적으로 잘못 해석하는 암호화와는 완전히 다릅니다.

인코딩 및 디코딩은 데이터 통신 및 저장에 사용됩니다. 민감한 정보를 전송하는 데 인코딩을 사용해서는 안됩니다.

URL 인코딩

URL은 ASCII 문자 집합을 사용하여 인터넷을 통해서만 보낼 수 있으며 URL에 ASCII 문자 이외의 특수 문자가 포함 된 경우 인코딩해야하는 경우가 있습니다. URL은 공백을 포함하지 않으며 더하기 (+) 기호 또는 % 20으로 대체됩니다.

ASCII 인코딩

브라우저 (클라이언트 측)는 웹 페이지에서 사용되는 문자 집합에 따라 입력을 인코딩하며 HTML5의 기본 문자 집합은 UTF-8입니다.

다음 표는 문자의 ASCII 기호와 동일한 기호를 보여주고 마지막으로 서버에 전달하기 전에 URL에서 사용할 수있는 대체-

ASCII	상징	바꿔 놓음
<32		% xx로 인코딩하십시오. 여기서 xx는 문자의 16 진 표현입니다.
32	우주	+ 또는 % 20
33	!	% 21
34	"	% 22
35	#	% 23
36	$	% 24
37	%	% 25
38	&	% 26
39	'	% 27
40	(	% 28
41	)	% 29
42	*	*
43	+	% 2B
44	,	% 2C
45	-	-
46	.	.
47	/	% 2F
48	0	0
49	1	1
50	2	2
51	삼	삼
52	4	4
53	5	5
54	6	6
55	7	7
56	8	8
57	9	9
58	:	% 3A
59	;	% 3B
60	>	% 3C
61	=	% 3D
62	>	% 3E
63	?	% 3F
64	@	% 40
65	ㅏ	ㅏ
66	비	비
67	씨	씨
68	디	디
69	이자형	이자형
70	에프	에프
71	지	지
72	H	H
73	나는	나는
74	제이	제이
75	케이	케이
76	엘	엘
77	미디엄	미디엄
78	엔	엔
79	영형	영형
80	피	피
81	큐	큐
82	아르 자형	아르 자형
83	에스	에스
84	티	티
85	유	유
86	V	V
87	W	W
88	엑스	엑스
89	와이	와이
90	지	지
91	[	% 5B
92	\	% 5C
93	]	% 5D
94	^	% 5E
95	_	_
96	`	% 60
97	ㅏ	ㅏ
98	비	비
99	씨	씨
100	디	디
101	이자형	이자형
102	에프	에프
103	지	지
104	h	h
105	나는	나는
106	제이	제이
107	케이	케이
108	엘	엘
109	미디엄	미디엄
110	엔	엔
111	영형	영형
112	피	피
113	큐	큐
114	아르 자형	아르 자형
115	에스	에스
116	티	티
117	유	유
118	V	V
119	w	w
120	엑스	엑스
121	와이	와이
122	지	지
123	{	% 7B
124	\|	% 7C
125	}	% 7D
126	~	% 7E
127		% 7F
> 127		% xx로 인코딩합니다. 여기서 xx는 문자의 16 진수 표현입니다.

암호화 란 무엇입니까?

암호화는 사용자가 민감한 정보를 저장하거나 안전하지 않은 네트워크를 통해 전송하여 의도 한 수신자 만 읽을 수 있도록 데이터를 암호화 및 해독하는 과학입니다.

특별한 조치없이 읽고 이해할 수있는 데이터를 호출 plaintext, 그 실체를 숨기기 위해 평문을 위장하는 방법은 encryption.

암호화 된 일반 텍스트는 암호 텍스트라고하며 암호화 된 데이터를 다시 일반 텍스트로 되 돌리는 프로세스는 다음과 같습니다. decryption.

보안 통신을 분석하고 차단하는 과학을 암호화 분석이라고합니다. 같은 일을 수행하는 사람들은 공격자라고도합니다.
암호화는 강하거나 약할 수 있으며 강점은 실제 평문을 복구하는 데 필요한 시간과 리소스로 측정됩니다.
따라서 강력한 암호화 메시지를 해독하려면 적절한 디코딩 도구가 필요합니다.
10 억 대의 컴퓨터가 초당 10 억 번의 검사를 수행하더라도 텍스트를 해독 할 수없는 몇 가지 암호화 기술이 있습니다.
컴퓨팅 파워가 날로 증가함에 따라 공격자로부터 데이터와 중요 정보를 보호하기 위해 암호화 알고리즘을 매우 강력하게 만들어야합니다.

암호화는 어떻게 작동합니까?

암호화 알고리즘은 키 (단어, 숫자 또는 구일 수 있음)와 함께 작동하여 일반 텍스트를 암호화하고 동일한 일반 텍스트가 다른 키를 사용하여 다른 암호 텍스트로 암호화합니다.

따라서 암호화 된 데이터는 암호화 알고리즘의 강도 및 키의 기밀성과 같은 매개 변수의 두 가지에 완전히 의존합니다.

암호화 기법

Symmetric Encryption− 기존 암호화라고도하는 기존 암호화는 암호화 및 복호화에 하나의 키만 사용하는 기술입니다. 예 : DES, Triple DES 알고리즘, MARS by IBM, RC2, RC4, RC5, RC6.

Asymmetric Encryption− 암호화를 위해 한 쌍의 키를 사용하는 공개 키 암호화입니다. 데이터를 암호화하는 공개 키와 해독을위한 개인 키입니다. 공개 키는 개인 키를 비밀로 유지하면서 사람들에게 공개됩니다. 예를 들어 RSA, DSA (Digital Signature Algorithm), Elgamal입니다.

Hashing− 해싱은 단방향 암호화로 되돌릴 수 없거나 적어도 쉽게 되돌릴 수없는 스크램블 된 출력을 생성합니다. 예를 들어, MD5 알고리즘입니다. 디지털 인증서, 디지털 서명, 암호 저장, 통신 확인 등을 만드는 데 사용됩니다.

SOP (Same Origin Policy)는 웹 애플리케이션 보안 모델에서 중요한 개념입니다.

동일 출처 정책이란 무엇입니까?

이 정책에 따라 다음과 같은 조합이 될 수있는 동일한 사이트에서 생성 된 페이지에서 실행되는 스크립트를 허용합니다.

Domain
Protocol
Port

예

이 동작의 원인은 보안입니다. 당신이있는 경우 try.com를 하나 개의 창에서 gmail.com 다른 창에서, 당신은 액세스 try.com에서 스크립트를 원하거나 사용자를 대신의 Gmail의 맥락에서 gmail.com의 내용이나 실행 동작을 수정하지 마십시오.

아래는 동일한 출처의 웹 페이지입니다. 앞에서 설명한 것처럼 동일한 출처는 도메인 / 프로토콜 / 포트를 고려합니다.

http://website.com
http://website.com/
http://website.com/my/contact.html

아래는 다른 출처의 웹 페이지입니다.

http://www.site.co.uk (다른 도메인)
http://site.org (다른 도메인)
https://site.com (다른 프로토콜)
http://site.com:8080 (다른 포트)

IE에 대한 동일한 출처 정책 예외

Internet Explorer에는 SOP에 대한 두 가지 주요 예외가 있습니다.

첫 번째는 '신뢰할 수있는 영역'과 관련이 있습니다. 두 도메인이 모두 신뢰도가 높은 영역에있는 경우 동일한 출처 정책을 완전히 적용 할 수 없습니다.
IE의 두 번째 예외는 포트와 관련이 있습니다. IE는 동일한 출처 정책에 대한 포트를 포함하지 않으므로 http://website.com 및 http://wesite.com:4444는 동일한 출처에서 간주되며 제한이 적용되지 않습니다.

쿠키 란?

쿠키는 나중에 브라우저에서 읽을 수 있도록 웹 브라우저에 저장하기 위해 웹 서버가 보내는 작은 정보입니다. 이렇게하면 브라우저가 특정 개인 정보를 기억합니다. 해커가 쿠키 정보를 확보하면 보안 문제가 발생할 수 있습니다.

쿠키의 속성

다음은 쿠키의 몇 가지 중요한 속성입니다.

일반적으로 컴퓨터의 브라우저 디렉토리에 저장된 ID 태그가있는 작은 텍스트 파일입니다.
웹 개발자는 사용자가 웹 사이트를 효율적으로 탐색하고 특정 기능을 수행 할 수 있도록 지원합니다.
사용자가 동일한 웹 사이트를 다시 검색 할 때 쿠키에 저장된 데이터는 웹 서버로 다시 전송되어 사용자의 이전 활동을 웹 사이트에 알립니다.
거대한 데이터베이스가 있고 로그인이 필요하며 사용자 정의 가능한 테마가있는 웹 사이트에서는 쿠키를 피할 수 없습니다.

쿠키 내용

쿠키에는 다음 정보가 포함되어 있습니다.

쿠키를 보낸 서버의 이름입니다.
쿠키의 수명.
값-일반적으로 임의로 생성 된 고유 번호입니다.

쿠키 유형

Session Cookies− 이러한 쿠키는 사용자가 브라우저를 닫을 때 삭제되는 임시 쿠키입니다. 사용자가 다시 로그인하더라도 해당 세션에 대한 새 쿠키가 생성됩니다.
Persistent cookies− 이러한 쿠키는 사용자가 삭제하거나 만료되지 않는 한 하드 디스크 드라이브에 남아 있습니다. 쿠키의 만료는 쿠키가 얼마나 오래 지속될 수 있는지에 따라 다릅니다.

쿠키 테스트

다음은 쿠키를 테스트하는 방법입니다.

Disabling Cookies− 테스터는 쿠키를 비활성화 한 후 웹 사이트에 대한 액세스를 확인하고 페이지가 제대로 작동하는지 확인해야합니다. 웹 사이트의 모든 페이지를 탐색하고 앱 충돌을 확인합니다. 또한 사이트를 이용하려면 쿠키가 필요하다는 사실을 사용자에게 알려야합니다.
Corrupting Cookies− 수행해야 할 또 다른 테스트는 쿠키를 손상시키는 것입니다. 동일한 작업을 수행하려면 사이트 쿠키의 위치를 찾아서 도메인의 내부 정보에 액세스하여 사이트를 해킹하는 데 사용할 수있는 가짜 / 잘못된 데이터로 수동으로 편집해야합니다.
Removing Cookies − 웹 사이트의 모든 쿠키를 제거하고 웹 사이트가 어떻게 반응하는지 확인하십시오.
Cross-Browser Compatibility − 또한 쿠키를 작성하는 모든 페이지에서 지원되는 모든 브라우저에서 쿠키가 올바르게 작성되고 있는지 확인하는 것도 중요합니다.
Editing Cookies− 애플리케이션이 쿠키를 사용하여 로그인 정보를 저장하는 경우 테스터로서 쿠키 또는 주소 표시 줄의 사용자를 다른 유효한 사용자로 변경해야합니다. 쿠키를 편집해도 다른 사용자 계정에 로그인 할 수 없습니다.

쿠키보기 및 편집

최신 브라우저는 브라우저 자체에서 정보를 제공하는 쿠키보기 / 편집을 지원합니다. 편집을 성공적으로 수행 할 수있는 mozilla / chrome 용 플러그인이 있습니다.

Firefox 용 쿠키 플러그인 편집
크롬 용이 쿠키 플러그인 편집

쿠키를 편집하려면 단계를 수행해야합니다.

여기 에서 Chrome 용 플러그인을 다운로드 하세요.
아래와 같이 크롬에서 '이 쿠키 편집'플러그인에 액세스하여 쿠키 값을 편집하십시오.

공격을 수행하기위한 참고 자료로 사용할 수있는 다양한 방법론 / 접근법이 있습니다.

웹 애플리케이션-PenTesting 방법론

공격 모델을 개발하는 동안 다음 표준을 고려할 수 있습니다.

다음 목록 중 OWASP가 가장 활발하고 많은 기여자가 있습니다. 웹 앱을 디자인하기 전에 각 개발 팀이 고려하는 OWASP 기술에 초점을 맞출 것입니다.

PTES − 침투 테스트 실행 표준
OSSTMM − 오픈 소스 보안 테스트 방법론 매뉴얼
OWASP 테스트 기법-개방형 웹 애플리케이션 보안 프로토콜

OWASP 상위 10

Open Web Application Security Protocol 팀은 최근 몇 년 동안 웹에서 더 널리 퍼진 상위 10 개 취약점을 발표했습니다. 다음은 웹 기반 애플리케이션에서 더 많이 발생하는 보안 결함 목록입니다.

신청-실습

각각의 기술을 이해하기 위해 샘플 애플리케이션으로 작업 해 보겠습니다. 학습 목적으로 보안 결함을 명시 적으로 개발 한 J2EE 애플리케이션 'WebGoat'에 대한 공격을 수행합니다.

webgoat 프로젝트에 대한 전체 세부 정보는 https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project. WebGoat 응용 프로그램을 다운로드하려면 다음으로 이동하십시오.https://github.com/WebGoat/WebGoat/wiki/Installation-(WebGoat-6.0) 다운로드 섹션으로 이동합니다.

다운로드 한 애플리케이션을 설치하려면 먼저 포트 8080에서 실행중인 애플리케이션이 없는지 확인하십시오. 단일 명령 (java -jar WebGoat-6.0.1-war-exec.jar)을 사용하여 설치할 수 있습니다. 자세한 내용은 WebGoat 설치를 방문하십시오.

설치 후, 다음으로 이동하여 애플리케이션에 액세스 할 수 있어야합니다. http://localhost:8080/WebGoat/attack 페이지는 아래와 같이 표시됩니다.

로그인 페이지에 표시된 게스트 또는 관리자의 자격 증명을 사용할 수 있습니다.

웹 프록시

클라이언트 (브라우저)와 서버 (우리의 경우 Webgoat 애플리케이션이 호스팅되는 시스템) 간의 트래픽을 가로 채려면 웹 프록시를 사용해야합니다. 다운로드 할 수있는 Burp 프록시를 사용합니다.https://portswigger.net/burp/download.html

아래 그림과 같이 무료 버전의 burp suite를 다운로드하면 충분합니다.

Burp Suite 구성

Burp Suite는 브라우저와 웹 서버가주고받는 정보의 각 패킷을 가로 챌 수있는 웹 프록시입니다. 이것은 클라이언트가 웹 서버에 정보를 보내기 전에 내용을 수정하는 데 도움이됩니다.

Step 1− 아래 그림과 같이 앱은 포트 8080에 설치되고 Burp는 포트 8181에 설치됩니다. Burp Suite를 시작하고 아래와 같이 포트 8181에서 가져 오려면 다음 설정을 지정하십시오.

Step 2− Burp 제품군이 트래픽을 가로 챌 수 있도록 Burp가 애플리케이션이 설치된 Port # 8080을 수신하는지 확인해야합니다. 이 설정은 아래와 같이 Burp Suite의 스코프 탭에서 수행해야합니다.

Step 3− 그런 다음 포트 8181 (Burp Suite 포트)을 수신하도록 브라우저 프록시 설정을 지정합니다. 따라서 우리는 아래와 같이 클라이언트 (브라우저)와 서버 (웹 서버) 사이의 트래픽을 가로 채도록 웹 프록시를 구성했습니다.

Step 4 − 구성의 스냅 샷은 아래와 같이 간단한 워크 플로 다이어그램의 도움으로 아래에 표시됩니다.

주입 기술은 응용 프로그램의 입력 필드를 사용하여 SQL 쿼리 또는 명령을 주입하는 것으로 구성됩니다.

웹 애플리케이션-주입

성공적인 SQL 주입은 데이터베이스에서 민감한 데이터를 읽고 수정할 수 있으며 데이터베이스에서 데이터를 삭제할 수도 있습니다. 또한 해커가 DBMS 종료 / 데이터베이스 삭제와 같은 데이터베이스 관리 작업을 수행 할 수 있습니다.

간단한 다이어그램을 통해이 결함의 위협 원, 공격 벡터, 보안 약점, 기술적 영향 및 비즈니스 영향을 이해하겠습니다.

예

응용 프로그램은 다음과 같은 취약한 SQL 호출의 구성에 신뢰할 수없는 데이터를 사용합니다.

String query = "SELECT * FROM EMP WHERE EMPID = '" + request.getParameter("id") + "'";

손에

Step 1 − 아래와 같이 애플리케이션의 SQL Injection 영역으로 이동합니다.

Step 2− 실습에서 주어진 것처럼, 우리는 인증을 우회하기 위해 String SQL Injection을 사용합니다. SQL 주입을 사용하여 올바른 암호를 사용하지 않고 보스 ( 'Neville')로 로그인합니다. Neville의 프로필을 볼 수 있고 모든 기능 (검색, 생성 및 삭제 포함)을 사용할 수 있는지 확인합니다.

Step 3 − 매개 변수를 'a'= 'a'또는 1 = 1로 전송하여 암호를 우회 할 수 있도록 SQL을 주입합니다.

Step 4 − Exploitation 이후, 아래와 같이 Admin 인 Neville로 로그인 할 수 있습니다.

SQL 주입 방지

SQL 주입을 방지하는 방법에는 여러 가지가 있습니다. 개발자는 코드를 작성할 때 그에 따라 특수 문자를 처리하는지 확인해야합니다. 확실히 개발자를위한 가이드 인 OWASP에서 사용할 수있는 치트 시트 / 예방 기술이 있습니다.

매개 변수가있는 쿼리 사용
모든 사용자 제공 입력 이스케이프
최종 사용자를 위해 데이터베이스에 대해 최소 권한 활성화

응용 프로그램과 관련된 인증 기능이 올바르게 구현되지 않으면 해커가 암호 또는 세션 ID를 손상 시키거나 다른 사용자 자격 증명을 사용하여 다른 구현 결함을 악용 할 수 있습니다.

간단한 다이어그램을 통해이 결함의 위협 원, 공격 벡터, 보안 약점, 기술적 영향 및 비즈니스 영향을 이해하겠습니다.

예

An e-commerce application supports URL rewriting, putting session IDs in the URL −

http://example.com/sale/saleitems/jsessionid=2P0OC2JSNDLPSKHCJUN2JV/?item=laptop

사이트의 인증 된 사용자는 할인 된 판매에 대해 알기 위해 URL을 친구에게 전달합니다. 그는 사용자가 세션 ID를 제공한다는 사실을 알지 못한 채 위의 링크를 이메일로 보냅니다. 그의 친구들이 링크를 사용할 때 그들은 그의 세션과 신용 카드를 사용합니다.

손에

Step 1− Webgoat에 로그인하고 '세션 관리 결함'섹션으로 이동합니다. 쿠키를 스푸핑하여 감성을 우회합시다. 아래는 시나리오의 스냅 샷입니다.

Step 2 − webgoat / webgoat 자격 증명을 사용하여 로그인하면 Burp Suite에서 JSESSION ID가 C8F3177CCAFF380441ABF71090748F2E이고 인증 성공시 AuthCookie = 65432ubphcfx임을 알 수 있습니다.

Step 3 − 자격 증명 측면 / 측면을 사용하여 로그인 할 때 Burp Suite에서 JSESSION ID가 C8F3177CCAFF380441ABF71090748F2E이고 인증 성공시 AuthCookie = 65432udfqtb임을 알 수 있습니다.

Step 4− 이제 AuthCookie 패턴을 분석해야합니다. 전반부 '65432'는 두 인증 모두에 공통입니다. 따라서 우리는 이제 webgoat 사용자의 경우 ubphcfx, aspect 사용자의 경우 udfqtb와 같은 authcookie 값의 마지막 부분을 분석하는 데 관심이 있습니다.

Step 5− AuthCookie 값을 자세히 살펴보면 마지막 부분은 사용자 이름과 길이가 같습니다. 따라서 사용자 이름이 일부 암호화 방법과 함께 사용되는 것이 분명합니다. 시행 착오 / 무력화 메커니즘을 통해 사용자 이름을 뒤집은 후 webgoat; taogbew로 끝나고 알파벳 앞의 문자가 AuthCookie로 사용됩니다. 즉 ubphcfx.

Step 6−이 쿠키 값을 전달하고 어떤 일이 발생하는지 살펴보면. 사용자 웹 염소로 인증 할 때 4 단계와 5 단계를 수행하여 동일한 AuthCookie를 찾아 사용자 Alice를 모의하도록 AuthCookie 값을 변경합니다.

메커니즘 방지

OWASP의 애플리케이션 보안 검증 표준에 정의 된 모든 인증 및 세션 관리 요구 사항을 충족하도록 강력한 인증 및 세션 관리 제어를 개발합니다.
개발자는 세션 ID를 훔치는 데 사용할 수있는 XSS 결함을 방지해야합니다.

크로스 사이트 스크립팅 (XSS)은 응용 프로그램이 신뢰할 수없는 데이터를 가져와 유효성 검사없이 클라이언트 (브라우저)로 보낼 때마다 발생합니다. 이를 통해 공격자는 피해자의 브라우저에서 악성 스크립트를 실행하여 사용자 세션을 가로 채거나 웹 사이트를 손상 시키거나 사용자를 악성 사이트로 리디렉션 할 수 있습니다.

간단한 다이어그램을 통해이 결함의 위협 원, 공격 벡터, 보안 약점, 기술적 영향 및 비즈니스 영향을 이해하겠습니다.

XSS의 유형

Stored XSS − 영구 XSS라고도하는 저장된 XSS는 데이터베이스 / 메시지 포럼 / 댓글 필드 등과 같은 대상 서버에 사용자 입력이 저장 될 때 발생합니다. 그러면 피해자는 웹 애플리케이션에서 저장된 데이터를 검색 할 수 있습니다.
Reflected XSS − 비 영구 XSS라고도하는 Reflected XSS는 사용자 입력이 웹 애플리케이션에서 오류 메시지 / 검색 결과 또는 요청의 일부로 사용자가 제공 한 입력으로 즉시 반환되고 사용자가 제공 한 데이터를 영구적으로 저장하지 않을 때 발생합니다.
DOM Based XSS − DOM 기반 XSS는 데이터 소스가 DOM에 있고 싱크도 DOM에 있으며 데이터 흐름이 브라우저를 벗어나지 않을 때 XSS의 한 형태입니다.

예

응용 프로그램은 유효성 검사없이 구성에 신뢰할 수없는 데이터를 사용합니다. 특수 문자는 이스케이프해야합니다.

http://www.webpage.org/task/Rule1?query=try

공격자는 브라우저에서 쿼리 매개 변수를 다음과 같이 수정합니다.

http://www.webpage.org/task/Rule1?query=<h3>Hello from XSS"</h3>

손에

Step 1− Webgoat에 로그인하고 크로스 사이트 스크립팅 (XSS) 섹션으로 이동합니다. XSS (Stored Cross-Site Scripting) 공격을 실행 해 보겠습니다. 아래는 시나리오의 스냅 샷입니다.

Step 2− 시나리오에 따라 시나리오 자체에서 언급 한 암호 'tom'을 사용하여 Tom으로 로그인하겠습니다. '프로필보기'를 클릭하고 편집 모드로 들어갑니다. tom이 공격자이므로 해당 편집 상자에 Java 스크립트를 삽입하겠습니다.

<script> 
   alert("HACKED")
</script>

Step 3 − 업데이트가 끝나 자마자 tom은 앱이 취약하다는 "해킹 됨"메시지가 포함 된 경고 상자를받습니다.

Step 4 − 이제 시나리오에 따라 jerry (HR)로 로그인하고 jerry가 삽입 된 스크립트의 영향을 받는지 확인해야합니다.

Step 5 − Jerry로 로그인 후 'Tom'을 선택하고 아래와 같이 '프로필보기'를 클릭합니다.

Jerry의 계정에서 Tom의 프로필을 보는 동안 그는 동일한 메시지 상자를 얻을 수 있습니다.

Step 6 −이 메시지 상자는 예시 일뿐 실제 공격자는 메시지 상자를 표시하는 것 이상을 수행 할 수 있습니다.

예방 메커니즘

개발자는 데이터가 배치되는 본문, 속성, JavaScript, CSS 또는 URL과 같은 HTML 컨텍스트를 기반으로 신뢰할 수없는 모든 데이터를 이스케이프해야합니다.
특수 문자를 입력으로 필요로하는 애플리케이션의 경우 유효한 입력으로 받아들이 기 전에 강력한 유효성 검사 메커니즘이 있어야합니다.

직접 개체 참조는 공격자가 이러한 참조를 조작하여 권한이없는 데이터에 액세스 할 수있는 유효성 검사 메커니즘없이 개발자가 파일, 디렉터리 또는 데이터베이스 키와 같은 내부 구현 개체에 대한 참조를 노출 할 때 발생할 수 있습니다.

간단한 다이어그램을 통해이 결함의 위협 원, 공격 벡터, 보안 약점, 기술적 영향 및 비즈니스 영향을 이해하겠습니다.

예

앱은 계정 정보에 액세스하는 SQL 호출에서 확인되지 않은 데이터를 사용합니다.

String sqlquery = "SELECT * FROM useraccounts WHERE account = ?";
PreparedStatement st = connection.prepareStatement(sqlquery, ??);
st.setString( 1, request.getParameter("acct"));
ResultSet results = st.executeQuery( );

공격자는 관리자를 가리 키도록 브라우저에서 쿼리 매개 변수를 수정합니다.

http://webapp.com/app/accountInfo?acct=admin

손에

Step 1− Webgoat에 로그인하고 액세스 제어 결함 섹션으로 이동합니다. 목표는 tomcat-users.xml이있는 경로를 탐색하여 검색하는 것입니다. 아래는 시나리오의 스냅 샷입니다.

Step 2 − 파일의 경로는 '현재 디렉터리 위치'필드에 표시됩니다.-C : \ Users \ userName $ \. extract \ webapps \ WebGoat \ lesson_plans \ en 또한 tomcat-users.xml 파일이 아래에 보관되어 있음을 알고 있습니다. C : \ xampp \ tomcat \ conf

Step 3− 현재 디렉터리를 완전히 탐색하고 C : \ Drive에서 탐색해야합니다. Burp Suite를 사용하여 트래픽을 차단하여 동일한 작업을 수행 할 수 있습니다.

Step 4 − 시도가 성공하면 "축하합니다.이 단원을 성공적으로 완료했습니다."라는 메시지와 함께 tomcat-users.xml이 표시됩니다.

예방 메커니즘

개발자는 다음 리소스 / 포인트를 가이드로 사용하여 개발 단계 자체에서 안전하지 않은 직접 개체 참조를 방지 할 수 있습니다.

개발자는 간접 개체 참조에 대해 하나의 사용자 또는 세션 만 사용해야합니다.
또한 신뢰할 수없는 소스에서 직접 개체 참조를 사용하기 전에 액세스를 확인하는 것이 좋습니다.

보안 설정이 기본값으로 정의, 구현 및 유지 될 때 잘못된 보안 구성이 발생합니다. 좋은 보안을 위해서는 애플리케이션, 웹 서버, 데이터베이스 서버 및 플랫폼에 대해 정의되고 배포 된 보안 구성이 필요합니다. 소프트웨어를 최신 상태로 유지하는 것도 똑같이 중요합니다.

예

잘못된 보안 구성의 몇 가지 전형적인 예는 다음과 같습니다.

서버에서 디렉토리 목록이 비활성화되어 있지 않고 공격자가 동일한 것을 발견하면 공격자는 단순히 디렉토리를 나열하여 파일을 찾아 실행할 수 있습니다. 또한 모든 사용자 지정 코드가 포함 된 실제 코드 기반을 얻은 다음 응용 프로그램에서 심각한 결함을 찾을 수도 있습니다.
앱 서버 구성을 사용하면 스택 추적을 사용자에게 반환하여 잠재적 인 결함을 노출 할 수 있습니다. 공격자는 오류 메시지가 제공하는 추가 정보를 가져 와서 침투하기에 충분합니다.
앱 서버는 일반적으로 보안이 취약한 샘플 앱과 함께 제공됩니다. 프로덕션 서버에서 제거하지 않으면 서버가 손상 될 수 있습니다.

손에

Step 1− Webgoat를 시작하고 안전하지 않은 구성 섹션으로 이동하여이 문제를 해결해 보겠습니다. 동일한 스냅 샷이 아래에 제공됩니다.

Step 2− 생각할 수있는 한 많은 옵션을 시도해 볼 수 있습니다. 구성 파일의 URL을 찾는 데 필요한 모든 것은 개발자가 구성 파일에 대한 일종의 명명 규칙을 따른다는 것을 알고 있습니다. 아래 나열된 모든 것이 될 수 있습니다. 일반적으로 BRUTE 힘 기술로 수행됩니다.

web.config
config
appname.config
conf

Step 3 − 다양한 옵션을 시도해 보면 'http://localhost:8080/WebGoat/conf'성공했습니다. 시도가 성공하면 다음 페이지가 표시됩니다.

예방 메커니즘

개발, QA, 프로덕션 환경과 같은 모든 환경은 쉽게 해킹 할 수없는 각 환경에서 사용되는 서로 다른 비밀번호를 사용하여 동일하게 구성되어야합니다.
구성 요소간에 효과적이고 안전한 분리를 제공하는 강력한 애플리케이션 아키텍처가 채택되고 있는지 확인합니다.
또한 자동 스캔을 실행하고 주기적으로 감사를 수행하여이 공격의 가능성을 최소화 할 수 있습니다.

온라인 응용 프로그램이 매일 인터넷에 넘쳐나고 있기 때문에 모든 응용 프로그램이 보안되지는 않습니다. 많은 웹 애플리케이션은 신용 카드 정보 / 은행 계좌 정보 / 인증 자격 증명과 같은 민감한 사용자 데이터를 적절하게 보호하지 않습니다. 해커는 신용 카드 사기, 신원 도용 또는 기타 범죄를 수행하기 위해 취약하게 보호되는 데이터를 훔칠 수 있습니다.

간단한 다이어그램을 통해이 결함의 위협 원, 공격 벡터, 보안 약점, 기술적 영향 및 비즈니스 영향을 이해하겠습니다.

예

잘못된 보안 구성의 전형적인 예는 다음과 같습니다.

사이트는 인증 된 모든 페이지에 SSL을 사용하지 않습니다. 이를 통해 공격자는 네트워크 트래픽을 모니터링하고 사용자 세션 쿠키를 훔쳐 사용자 세션을 가로 채거나 개인 데이터에 액세스 할 수 있습니다.
응용 프로그램은 신용 카드 번호를 암호화 된 형식으로 데이터베이스에 저장합니다. 검색시 암호가 해독되어 해커가 SQL 주입 공격을 수행하여 모든 민감한 정보를 일반 텍스트로 검색 할 수 있습니다. 이는 공개 키를 사용하여 신용 카드 번호를 암호화하고 백엔드 애플리케이션이 개인 키를 사용하여이를 해독하도록 허용함으로써 방지 할 수 있습니다.

손에

Step 1− WebGoat를 시작하고 "안전하지 않은 저장소"섹션으로 이동합니다. 동일한 스냅 샷이 아래에 표시됩니다.

Step 2− 사용자 이름과 비밀번호를 입력합니다. 이전에 논의한 다른 종류의 인코딩 및 암호화 방법론을 배울 때입니다.

예방 메커니즘

민감한 데이터를 불필요하게 저장하지 않는 것이 좋으며 더 이상 필요하지 않은 경우 가능한 한 빨리 스크랩해야합니다.
강력한 표준 암호화 알고리즘을 사용하고 적절한 키 관리가 이루어 지도록하는 것이 중요합니다.
비밀번호와 같은 민감한 데이터를 수집하는 양식에서 자동 완성을 비활성화하고 민감한 데이터가 포함 된 페이지에 대한 캐싱을 비활성화하여이를 방지 할 수도 있습니다.

대부분의 웹 응용 프로그램은 사용자가 해당 기능에 액세스 할 수 있도록하기 전에 기능 수준 액세스 권한을 확인합니다. 그러나 서버에서 동일한 액세스 제어 검사를 수행하지 않으면 해커가 적절한 권한없이 애플리케이션에 침투 할 수 있습니다.

간단한 다이어그램을 통해이 결함의 위협 원, 공격 벡터, 보안 약점, 기술적 영향 및 비즈니스 영향을 이해하겠습니다.

예

다음은 Missing Function Level Access Control의 전형적인 예입니다.

해커는 단순히 대상 URL을 강제합니다. 일반적으로 관리자 액세스에는 인증이 필요하지만 응용 프로그램 액세스가 확인되지 않으면 인증되지 않은 사용자가 관리자 페이지에 액세스 할 수 있습니다.

' Below URL might be accessible to an authenticated user
http://website.com/app/standarduserpage

' A NON Admin user is able to access admin page without authorization.
http://website.com/app/admin_page

손에

Step 1 − 먼저 사용자 목록과 액세스 권한을 살펴보고 계정 관리자로 로그인하겠습니다.

Step 2 − 다양한 조합을 시도해 보면 Larry가 자원 계정 관리자에 액세스 할 수 있음을 알 수 있습니다.

예방 메커니즘

인증 메커니즘은 기본적으로 모든 액세스를 거부하고 모든 기능에 대한 특정 역할에 대한 액세스를 제공해야합니다.
워크 플로 기반 응용 프로그램에서 사용자가 리소스에 액세스 할 수 있도록 허용하기 전에 사용자의 상태를 확인합니다.

CSRF 공격은 인증 된 사용자 (피해자)가 피해자의 세션 쿠키를 포함한 위조 된 HTTP 요청을 취약한 웹 애플리케이션에 전송하도록하여 공격자가 피해자의 브라우저가 취약한 앱이 다음의 합법적 인 요청으로 인식하는 요청을 생성하도록 강제 할 수 있도록합니다. 피해자.

간단한 다이어그램을 통해이 결함의 위협 원, 공격 벡터, 보안 약점, 기술적 영향 및 비즈니스 영향을 이해하겠습니다.

예

다음은 CSRF의 전형적인 예입니다.

Step 1 − 취약한 애플리케이션이 암호화없이 일반 텍스트로 상태 변경 요청을 전송한다고 가정 해 보겠습니다.

http://bankx.com/app?action=transferFund&amount=3500&destinationAccount=4673243243

Step 2 − 이제 해커는 공격자가 제어하는 다양한 사이트에 저장된 이미지에 요청을 삽입하여 피해자의 계정에서 공격자의 계정으로 돈을 이체하는 요청을 구성합니다.

<img src = "http://bankx.com/app?action=transferFunds&amount=14000&destinationAccount=attackersAcct#" 
   width = "0" height = "0" />

손에

Step 1− 이미지에 자바 스크립트를 삽입하여 CSRF 위조를 수행해 보겠습니다. 문제의 스냅 샷은 다음과 같습니다.

Step 2 -이제 전송을 1x1 이미지로 모의하고 피해자가 동일한 이미지를 클릭하도록해야합니다.

Step 3 − 메시지 제출시 아래 강조 표시된 메시지가 표시됩니다.

Step 4− 이제 피해자가 다음 URL을 클릭하면 전송이 실행되며, Burp Suite를 사용하여 사용자의 행동을 가로채는 것을 확인할 수 있습니다. 아래와 같이 Get 메시지에서 전송을 확인할 수 있습니다.

Step 5 − 이제 새로 고침을 클릭하면 레슨 완료 표시가 나타납니다.

예방 메커니즘

CSRF는 노출되기 쉬운 URL이 아닌 HTTP 요청 본문으로 전송되는 숨겨진 필드에 고유 한 토큰을 생성하여 방지 할 수 있습니다.
CSRF를 보호하기 위해 사용자에게 재 인증을 강요하거나 사용자임을 증명합니다. 예 : CAPTCHA.

이러한 종류의 위협은 앱 내에서 사용되는 라이브러리 및 프레임 워크와 같은 구성 요소가 거의 항상 전체 권한으로 실행될 때 발생합니다. 취약한 구성 요소가 악용되면 해커의 작업이 더 쉽게 심각한 데이터 손실 또는 서버 탈취를 유발할 수 있습니다.

간단한 다이어그램을 통해이 결함의 위협 원, 공격 벡터, 보안 약점, 기술적 영향 및 비즈니스 영향을 이해하겠습니다.

예

다음 예는 알려진 취약점이있는 구성 요소를 사용하는 것입니다.

공격자는 ID 토큰을 제공하지 않아 모든 웹 서비스를 완전한 권한으로 호출 할 수 있습니다.
Expression Language 주입 취약점이있는 원격 코드 실행은 Java 기반 앱용 Spring Framework를 통해 도입되었습니다.

예방 메커니즘

데이터베이스 / 프레임 워크에만 국한되지 않고 웹앱에서 사용되는 모든 구성 요소와 버전을 식별합니다.
공용 데이터베이스, 프로젝트 메일 링리스트 등과 같은 모든 구성 요소를 최신 상태로 유지하십시오.
본질적으로 취약한 구성 요소 주위에 보안 래퍼를 추가합니다.

인터넷에있는 대부분의 웹 응용 프로그램은 사용자를 다른 페이지 나 다른 외부 웹 사이트로 리디렉션하고 전달하는 경우가 많습니다. 그러나 이러한 페이지의 신뢰성을 확인하지 않고 해커는 피해자를 피싱 또는 맬웨어 사이트로 리디렉션하거나 전달을 사용하여 승인되지 않은 페이지에 액세스 할 수 있습니다.

간단한 다이어그램을 통해이 결함의 위협 원, 공격 벡터, 보안 약점, 기술적 영향 및 비즈니스 영향을 이해하겠습니다.

예

검증되지 않은 리디렉션 및 전달의 몇 가지 고전적인 예는 다음과 같습니다.

매개 변수 소요 redirect.jsp, - 우리는 응용 프로그램이 페이지가 있다고 가정 해 봅시다 redirectrul을 . 해커는 피싱을 수행하거나 멀웨어를 설치하는 사용자를 리디렉션하는 악성 URL을 추가합니다.

http://www.mywebapp.com/redirect.jsp?redirectrul=hacker.com

사용자를 사이트의 다른 부분으로 전달하는 데 사용되는 모든 웹 응용 프로그램입니다. 동일한 작업을 수행하기 위해 일부 페이지는 매개 변수를 사용하여 작업이 성공한 경우 사용자가 리디렉션되어야하는 위치를 나타냅니다. 공격자는 응용 프로그램의 액세스 제어 검사를 통과하는 URL을 만든 다음 공격자가 액세스 할 수없는 관리 기능으로 공격자를 전달합니다.

http://www.mywebapp.com/checkstatus.jsp?fwd=appadmin.jsp

예방 메커니즘

리디렉션 및 전달을 사용하지 않는 것이 좋습니다.
피할 수없는 경우 대상을 리디렉션 할 때 사용자 매개 변수를 포함하지 않고 수행해야합니다.

AJAX (Asynchronous Javascript and XML)는 풍부한 사용자 경험을 제공하기 위해 웹 애플리케이션을 개발하는 데 사용되는 최신 기술 중 하나입니다. 신기술이기 때문에 아직 완성되지 않은 많은 보안 문제가 있으며 아래는 AJAX의 몇 가지 보안 문제입니다.

보안해야 할 입력이 많을수록 공격 표면이 더 커집니다.
또한 응용 프로그램의 내부 기능을 노출합니다.
인증 정보 및 세션을 보호하지 못했습니다.
클라이언트 측과 서버 측 사이에는 매우 좁은 경계가 있으므로 보안 실수를 저지를 가능성이 있습니다.

예

다음은 AJAX 보안의 예입니다.

2006 년에 웜은 Yahoo Mail의 onload 이벤트 처리 취약점을 이용하여 XSS 및 AJAX를 사용하여 yahoo 메일 서비스를 감염 시켰습니다. 감염된 이메일이 열렸을 때 웜은 자바 스크립트를 실행하여 감염된 사용자의 모든 Yahoo 연락처에 복사본을 보냅니다.

손에

Step 1− XML 주입을 사용하여 허용 된 보상 세트에 더 많은 보상을 추가해야합니다. 아래는 시나리오의 스냅 샷입니다.

Step 2− Burp Suite를 사용하여 요청과 응답을 모두 가로채는 지 확인하십시오. 아래와 같은 설정.

Step 3− 시나리오에 주어진 계좌 번호를 입력합니다. 우리는 우리가받을 수있는 모든 보상 목록을 얻을 수 있습니다. 5 개 중 3 개를받을 수 있습니다.

Step 4− 이제 '제출'을 클릭하고 응답 XML에서 얻은 내용을 살펴 보겠습니다. 아래에서 볼 수 있듯이 우리가받을 수있는 세 가지 보상은 XML로 우리에게 전달됩니다.

Step 5 − 이제 해당 XML을 편집하고 다른 두 가지 보상도 추가하겠습니다.

Step 6-이제 모든 보상이 사용자가 선택할 수 있도록 표시됩니다. 추가 한 항목을 선택하고 '제출'을 클릭합니다.

Step 7 − "* 축하합니다.이 레슨을 성공적으로 완료했습니다."라는 메시지가 나타납니다.

예방 메커니즘

클라이언트 측-

.innerHtml 대신 .innerText를 사용하십시오.
eval을 사용하지 마십시오.
보안을 위해 클라이언트 로직에 의존하지 마십시오.
직렬화 코드를 작성하지 마십시오.
XML을 동적으로 작성하지 마십시오.
클라이언트에게 비밀을 전송하지 마십시오.
클라이언트 측 코드에서 암호화를 수행하지 마십시오.
클라이언트 측에서 보안 영향 논리를 수행하지 마십시오.

서버 측-

CSRF 보호를 사용하십시오.
직렬화 코드를 작성하지 마십시오.
서비스는 사용자가 직접 호출 할 수 있습니다.
XML을 직접 작성하지 말고 프레임 워크를 사용하십시오.
JSON을 직접 빌드하지 말고 기존 프레임 워크를 사용하세요.

최신 웹 기반 애플리케이션에서 웹 서비스의 사용은 불가피하며 공격에 취약합니다. 웹 서비스 요청은 여러 웹 사이트에서 가져 오기 때문에 개발자는 해커의 침입을 방지하기 위해 몇 가지 추가 조치를 취해야합니다.

손에

Step 1− Webgoat의 웹 서비스 영역으로 이동하고 WSDL 스캐닝으로 이동합니다. 이제 다른 계좌 번호의 신용 카드 정보를 가져와야합니다. 시나리오의 스냅 샷은 다음과 같습니다.

Step 2 − 이름을 선택하면 SOAP 요청 xml을 통해 'getFirstName'함수 호출이 이루어집니다.

Step 3− WSDL을 열면 'getCreditCard'와 함께 신용 카드 정보를 검색하는 방법이 있음을 알 수 있습니다. 이제 아래와 같이 Burp 제품군을 사용하여 입력을 변조하겠습니다.

Step 4 − 이제 아래와 같이 Burp suite를 사용하여 입력을 수정하겠습니다. −

Step 5 − 다른 사용자의 신용 카드 정보를 얻을 수 있습니다.

예방 메커니즘

SOAP 메시지는 XML 기반이므로 전달 된 모든 자격 증명은 텍스트 형식으로 변환되어야합니다. 따라서 항상 암호화되어야하는 민감한 정보를 전달하는 데 매우주의해야합니다.
패킷의 무결성을 보장하기 위해 적용된 체크섬과 같은 메커니즘을 구현하여 메시지 무결성을 보호합니다.
메시지 기밀성 보호-대칭 세션 키를 보호하기 위해 비대칭 암호화가 적용됩니다. 대칭 세션 키는 많은 구현에서 하나의 통신에만 유효하며 이후에 삭제됩니다.

프로그램이 임시 데이터 저장 영역 (버퍼)에 저장하려는 것보다 더 많은 데이터를 저장하려고하면 버퍼 오버플로가 발생합니다. 한정된 양의 데이터를 포함하도록 버퍼가 생성되기 때문에 추가 정보가 인접한 버퍼로 오버플로되어 그 안에있는 유효한 데이터가 손상 될 수 있습니다.

예

다음은 버퍼 오버 플로우의 전형적인 예입니다. 이는 동작을 제어하기 위해 외부 데이터에 의존하는 첫 번째 시나리오로 인해 발생하는 간단한 버퍼 오버 플로우를 보여줍니다. 사용자가 입력 한 데이터의 양을 제한 할 수있는 방법이 없으며 프로그램의 동작은 사용자가 입력 한 문자 수에 따라 다릅니다.

...
   char bufr[BUFSIZE]; 
   gets(bufr);
   ...

손에

Step 1− 인터넷에 접속하려면 이름과 방 번호로 로그인해야합니다. 다음은 시나리오 스냅 샷입니다.

Step 2 − 또한 Burp Suite에서 "숨겨진 양식 필드 숨기기 해제"를 아래와 같이 활성화합니다. −

Step 3− 이제 이름과 방 번호 필드에 입력을 보냅니다. 우리는 또한 방 번호 필드에 꽤 큰 숫자를 주입하려고합니다.

Step 4− 숨겨진 필드는 아래와 같이 표시됩니다. 약관 동의를 클릭합니다.

Step 5 − 공격이 성공하여 버퍼 오버플로의 결과로 인접한 메모리 위치를 읽기 시작하고 아래와 같이 사용자에게 표시됩니다.

Step 6− 이제 표시된 데이터를 사용하여 로그인하겠습니다. 로깅 후 다음 메시지가 표시됩니다.

예방 메커니즘

코드 검토
개발자 교육
컴파일러 도구
안전한 기능 개발
정기 스캔

서비스 거부 (DoS) 공격은 해커가 네트워크 리소스를 사용할 수 없게 만드는 시도입니다. 일반적으로 인터넷에 연결된 호스트를 일시적으로 또는 무기한으로 중단합니다. 이러한 공격은 일반적으로 은행, 신용 카드 결제 게이트웨이와 같은 미션 크리티컬 웹 서버에서 호스팅되는 서비스를 대상으로합니다.

DoS의 증상

비정상적으로 느린 네트워크 성능.
특정 웹 사이트를 사용할 수 없습니다.
웹 사이트에 액세스 할 수 없습니다.
수신 된 스팸 이메일 수가 급격히 증가했습니다.
웹 또는 인터넷 서비스에 대한 장기적인 액세스 거부.
특정 웹 사이트를 사용할 수 없습니다.

손에

Step 1− WebGoat를 시작하고 '서비스 거부'섹션으로 이동합니다. 시나리오의 스냅 샷은 다음과 같습니다. 최대 DB 스레드 풀 크기를 위반하여 여러 번 로그인해야합니다.

Step 2− 먼저 유효한 로그인 목록을 가져와야합니다. 이 경우 SQL 주입을 사용합니다.

Step 3 − 시도가 성공하면 유효한 모든 자격 증명을 사용자에게 표시합니다.

Step 4− 이제 DoS 공격을 성공적으로 수행하기 위해 최소 3 개의 세션에서 이러한 사용자 각각에 로그인합니다. DB 연결은 2 개의 스레드 만 처리 할 수 있다는 것을 알고 있듯이 모든 로그인을 사용하면 3 개의 스레드가 생성되어 공격이 성공합니다.

예방 메커니즘

철저한 입력 유효성 검사를 수행합니다.
CPU를 많이 사용하는 작업을 피하십시오.
시스템 디스크에서 데이터 디스크를 분리하는 것이 좋습니다.

개발자는 종종 잠재적으로 취약한 입력을 파일과 직접 사용하거나 연결하거나 입력 파일이 진짜라고 가정합니다. 데이터가 제대로 확인되지 않으면 취약한 콘텐츠가 웹 서버에서 처리되거나 호출 될 수 있습니다.

예

고전적인 예 중 일부는 다음과 같습니다.

.jsp 파일을 웹 트리에 업로드합니다.
크기를 조정할 .gif를 업로드하세요.
대용량 파일을 업로드하세요.
태그가 포함 된 파일을 업로드합니다.
.exe 파일을 웹 트리에 업로드합니다.

손에

Step 1− WebGoat를 실행하고 악성 파일 실행 섹션으로 이동합니다. 시나리오의 스냅 샷은 다음과 같습니다.

Step 2 −이 강의를 완료하려면 위에서 언급 한 위치에 guest.txt를 업로드해야합니다.

Step 3− jsp 실행시 guest.txt 파일이 생성되도록 jsp 파일을 생성하겠습니다. jsp의 이름 지정은 jsp 파일의 내용을 실행하므로이 컨텍스트에서 수행 할 역할이 없습니다.

<HTML> 
   <% java.io.File file = new 
      java.io.File("C:\\Users\\username$\\.extract\\webapps\\WebGoat\\mfe_target\\guest.txt"); 
      file.createNewFile(); %> 
</HTML>

Step 4− 이제 jsp 파일을 업로드하고 업로드 후 동일한 링크 위치를 복사합니다. 업로드에 이미지가 필요하지만 jsp를 업로드하고 있습니다.

Step 5 − jsp 파일로 이동하면 사용자에게 메시지가 표시되지 않습니다.

Step 6 − 이제 jsp 파일을 업로드 한 세션을 새로 고치면 "* 축하합니다. 레슨을 성공적으로 완료했습니다"라는 메시지가 표시됩니다.

예방 메커니즘

웹 사이트 권한을 사용하여 웹 사이트를 보호합니다.
웹 애플리케이션 보안을위한 대책을 채택하십시오.
IIS 7.0의 기본 제공 사용자 및 그룹 계정을 이해합니다.

응용 프로그램의 보안 테스트를 수행하는 데 사용할 수있는 다양한 도구가 있습니다. 종단 간 보안 테스트를 수행 할 수있는 도구는 거의 없지만 일부는 시스템에서 특정 유형의 결함을 발견하는 데 전념합니다.

오픈 소스 도구

일부 오픈 소스 보안 테스트 도구는 다음과 같습니다.

S. 아니.	도구 이름
1	Zed Attack Proxy 보안 결함을 발견하기위한 자동 스캐너 및 기타 도구를 제공합니다. https://www.owasp.org
2	OWASP WebScarab Http 및 Https 요청 분석을 위해 Java로 개발되었습니다. https://www.owasp.org/index.php
삼	OWASP Mantra 다국어 보안 테스트 프레임 워크 지원 https://www.owasp.org/index.php/OWASP_Mantra_-_Security_Framework
4	Burp Proxy 트래픽 차단 및 수정을위한 도구이며 사용자 지정 SSL 인증서와 함께 작동합니다. https://www.portswigger.net/Burp/
5	Firefox Tamper Data tamperdata를 사용하여 HTTP / HTTPS 헤더 및 게시 매개 변수를보고 수정합니다. https://addons.mozilla.org/en-US
6	Firefox Web Developer Tools 웹 개발자 확장은 다양한 웹 개발자 도구를 브라우저에 추가합니다. https://addons.mozilla.org/en-US/firefox
7	Cookie Editor 사용자가 쿠키를 추가, 삭제, 편집, 검색, 보호 및 차단할 수 있습니다. https://chrome.google.com/webstore

특정 도구 세트

다음 도구는 시스템에서 특정 유형의 취약성을 발견하는 데 도움이됩니다.

S. 아니.	링크
1	DOMinator Pro − Testing for DOM XSS https://dominator.mindedsecurity.com/
2	OWASP SQLiX − SQL Injection https://www.owasp.org/index.php
삼	Sqlninja − SQL Injection http://sqlninja.sourceforge.net/
4	SQLInjector − SQL Injection https://sourceforge.net/projects/safe3si/
5	sqlpowerinjector − SQL Injection http://www.sqlpowerinjector.com/
6	SSL Digger − Testing SSL https://www.mcafee.com/us/downloads/free-tools
7	THC-Hydra − Brute Force Password https://www.thc.org/thc-hydra/
8	Brutus − Brute Force Password http://www.hoobie.net/brutus/
9	Ncat − Brute Force Password https://nmap.org/ncat/
10	OllyDbg − Testing Buffer Overflow http://www.ollydbg.de/
11	Spike − Testing Buffer Overflow https://www.immunitysec.com/downloads/SPIKE2.9.tgz
12	Metasploit − Testing Buffer Overflow https://www.metasploit.com/

상용 블랙 박스 테스트 도구

다음은 우리가 개발하는 응용 프로그램에서 보안 문제를 발견하는 데 도움이되는 몇 가지 상용 블랙 박스 테스트 도구입니다.

S. 아니	수단
1	NGSSQuirreL https://www.nccgroup.com/en/our-services
2	IBM AppScan https://www-01.ibm.com/software/awdtools/appscan/
삼	Acunetix Web Vulnerability Scanner https://www.acunetix.com/
4	NTOSpider https://www.ntobjectives.com/products/ntospider.php
5	SOAP UI https://www.soapui.org/Security/getting-started.html
6	Netsparker https://www.mavitunasecurity.com/netsparker/
7	HP WebInspect http://www.hpenterprisesecurity.com/products

무료 소스 코드 분석기

S. 아니	수단
1	OWASP Orizon https://www.owasp.org/index.php
2	OWASP O2 https://www.owasp.org/index.php/OWASP_O2_Platform
삼	SearchDiggity https://www.bishopfox.com/resources/tools
4	FXCOP https://www.owasp.org/index.php/FxCop
5	Splint http://splint.org/
6	Boon https://www.cs.berkeley.edu/~daw/boon/
7	W3af http://w3af.org/
8	FlawFinder https://www.dwheeler.com/flawfinder/
9	FindBugs http://findbugs.sourceforge.net/

상용 소스 코드 분석기

이 분석기는 취약성에 취약한 소스 코드의 약점을 검사, 감지 및보고합니다.

S. 아니	수단
1	Parasoft C/C++ test https://www.parasoft.com/cpptest/
2	HP Fortify http://www.hpenterprisesecurity.com/products
삼	Appscan http://www-01.ibm.com/software/rational/products
4	Veracode https://www.veracode.com
5	Armorize CodeSecure http://www.armorize.com/codesecure/
6	GrammaTech https://www.grammatech.com/