변수가 HTTP GET을 통해 전송 된 변수보다 HTTP POST를 통해 전송되므로 더 큰 보안이 제공되지 않습니다.
HTTP / 1.1은 요청을 보내는 많은 메소드를 제공합니다 .
- 옵션
- 가져 오기
- 머리
- 게시하다
- 놓다
- 지우다
- 자취
- 잇다
GET을 사용하여 다음 HTML 문서가 있다고 가정 해 봅시다.
<html>
<body>
<form action="http://example.com" method="get">
User: <input type="text" name="username" /><br/>
Password: <input type="password" name="password" /><br/>
<input type="hidden" name="extra" value="lolcatz" />
<input type="submit"/>
</form>
</body>
</html>
브라우저는 무엇을 요구합니까? 다음과 같이 묻습니다.
GET /?username=swordfish&password=hunter2&extra=lolcatz HTTP/1.1
Host: example.com
Connection: keep-alive
Accept: application/xml,application/xhtml+xml,text/html;q=0.9,text/ [...truncated]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) [...truncated]
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
이제 요청 메소드를 POST로 변경했다고 가정 해 봅시다.
POST / HTTP/1.1
Host: example.com
Connection: keep-alive
Content-Length: 49
Cache-Control: max-age=0
Origin: null
Content-Type: application/x-www-form-urlencoded
Accept: application/xml,application/xhtml+xml,text/ [...truncated]
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; [...truncated]
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
username=swordfish&password=hunter2&extra=lolcatz
BOTH 이 HTTP 요청은 다음과 같습니다 :
- 암호화되지 않음
- 두 예 모두에 포함
- 전복 될 수 있으며 MITM 공격을받을 수 있습니다.
- 타사 및 스크립트 봇으로 쉽게 재현 할 수 있습니다.
많은 브라우저 가 POST / GET 이외의 HTTP 메소드를 지원하지 않습니다.
많은 브라우저 비헤이비어가 페이지 주소를 저장하지만 이것이 다른 문제를 무시할 수있는 것은 아닙니다.
구체적으로 말하면 :
하나는 본질적으로 다른 것보다 더 안전합니까? POST는 URL에 정보를 노출시키지 않지만 그 안에 실제 가치가 있습니까? 아니면 모호함을 통한 보안입니까? 가장 좋은 방법은 무엇입니까?
HTTP를 사용하기 위해 사용하는 소프트웨어는 한 가지 방법으로 요청 변수를 저장하는 경향이 있지만 다른 방법은 아니지만 다른 사람이 브라우저 기록 또는 h4x0r1ng를 이해한다고 생각하는 10 세의 다른 순진한 공격을 보지 못하기 때문입니다. 또는 기록 저장소를 확인하는 스크립트입니다. 히스토리 저장소를 확인할 수있는 스크립트가있는 경우 네트워크 트래픽을 확인하는 스크립트를 쉽게 가질 수 있으므로 모호성을 통한이 전체 보안은 스크립트 키즈 및 질투하는 여자 친구에게만 모호함을 제공합니다.
https를 통해 POST 데이터는 인코딩되지만 타사에서 URL을 스니핑 할 수 있습니까?
SSL 작동 방식은 다음과 같습니다. 위에서 보낸 두 요청을 기억하십니까? SSL에서 다음과 같이 표시 됩니다. example.com이 SSL에서 응답하지 않으므로 페이지를 https://encrypted.google.com/ 으로 변경했습니다 .
SSL을 통한 POST
q5XQP%RWCd2u#o/T9oiOyR2_YO?yo/3#tR_G7 2_RO8w?FoaObi)
oXpB_y?oO4q?`2o?O4G5D12Aovo?C@?/P/oOEQC5v?vai /%0Odo
QVw#6eoGXBF_o?/u0_F!_1a0A?Q b%TFyS@Or1SR/O/o/_@5o&_o
9q1/?q$7yOAXOD5sc$H`BECo1w/`4?)f!%geOOF/!/#Of_f&AEI#
yvv/wu_b5?/o d9O?VOVOFHwRO/pO/OSv_/8/9o6b0FGOH61O?ti
/i7b?!_o8u%RS/Doai%/Be/d4$0sv_%YD2_/EOAO/C?vv/%X!T?R
_o_2yoBP)orw7H_yQsXOhoVUo49itare#cA?/c)I7R?YCsg ??c'
(_!(0u)o4eIis/S8Oo8_BDueC?1uUO%ooOI_o8WaoO/ x?B?oO@&
Pw?os9Od!c?/$3bWWeIrd_?( `P_C?7_g5O(ob(go?&/ooRxR'u/
T/yO3dS&??hIOB/?/OI?$oH2_?c_?OsD//0/_s%r
SSL을 통한 GET
rV/O8ow1pc`?058/8OS_Qy/$7oSsU'qoo#vCbOO`vt?yFo_?EYif)
43`I/WOP_8oH0%3OqP_h/cBO&24?'?o_4`scooPSOVWYSV?H?pV!i
?78cU!_b5h'/b2coWD?/43Tu?153pI/9?R8!_Od"(//O_a#t8x?__
bb3D?05Dh/PrS6_/&5p@V f $)/xvxfgO'q@y&e&S0rB3D/Y_/fO?
_'woRbOV?_!yxSOdwo1G1?8d_p?4fo81VS3sAOvO/Db/br)f4fOxt
_Qs3EO/?2O/TOo_8p82FOt/hO?X_P3o"OVQO_?Ww_dr"'DxHwo//P
oEfGtt/_o)5RgoGqui&AXEq/oXv&//?%/6_?/x_OTgOEE%v (u(?/
t7DX1O8oD?fVObiooi'8)so?o??`o"FyVOByY_ Supo? /'i?Oi"4
tr'9/o_7too7q?c2Pv
(참고 : HEX를 ASCII로 변환했는데 그중 일부는 표시 할 수 없어야합니다)
전체 HTTP 대화는 암호화되며 통신에서 유일하게 보이는 부분은 TCP / IP 계층에 있습니다 (IP 주소 및 연결 포트 정보를 의미 함).
여기서 큰 대담한 진술을하겠습니다. 귀하의 웹 사이트는 다른 HTTP 방법보다 하나의 HTTP 방법에 비해 더 큰 보안을 제공하지 않으며 전 세계의 해커와 신입생은 내가 방금 시연 한 방법을 정확히 알고 있습니다. 보안을 원하면 SSL을 사용하십시오. 브라우저는 히스토리를 저장하는 경향이 있습니다. RFC2616 9.1.1에서는 GET을 사용하여 조치를 수행하지 말 것을 권장하지만 POST가 보안을 제공한다고 생각하는 것은 옳지 않다고 생각합니다.
POST가 유일하게 보안 대책은 무엇입니까? 브라우저 기록을 넘나 드는 질투심에 대한 보호. 그게 다야. 나머지 세계는 당신을 비웃는 당신의 계정에 로그인되어 있습니다.
POST가 안전하지 않은 이유를 추가로 보여주기 위해 Facebook은 POST 요청을 모든 곳에서 사용하므로 FireSheep 와 같은 소프트웨어는 어떻게 존재할 수 있습니까?
HTTPS를 사용하고 사이트에 XSS 취약점 이없는 경우에도 CSRF 로 공격을받을 수 있습니다 . 요컨대,이 공격 시나리오는 피해자 (사이트 또는 서비스의 사용자)가 이미 로그인하여 적절한 쿠키를 가지고 있다고 가정하고 피해자의 브라우저는 귀하의 (아마도 안전한) 사이트에 무언가를하도록 요청됩니다. CSRF에 대한 보호 기능이없는 경우에도 공격자는 피해자 자격 증명으로 작업을 계속 실행할 수 있습니다. 공격자는 서버의 응답이 피해자의 브라우저로 전송되기 때문에 서버 응답을 볼 수 없지만 일반적으로 그 시점에서 피해는 이미 이루어졌습니다.