[번역] 웝보안의 간단한 소개
A quick introduction to web security
content-security-policy:
default-src * data: blob:;
script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtua
원본 URL : https://medium.freecodecamp.org/a-quick-introduction-to-web-security-f90beaf4dd41
웹 보안에 대한 간략한 소개
CORS, CSP, HSTS 및 모든 웹 보안 머리 글자에 대한 웹 개발자의 입문서!
사진 호세 Fontano 에 Unsplash
개인 데이터가 유출 될까봐 걱정하는 사용자입니다.
등등.
이 게시물은 일반적인 웹 보안 머리 글자 어를 이해하기 쉽지만 여전히 정확한 방식으로 설명합니다.
먼저 보안에 대한 몇 가지 핵심 개념을 이해해야합니다.
두 가지 핵심 보안 개념
아무도 100 % 안전하지 않습니다.
100 % 해킹으로부터 보호 받는다는 개념은 없습니다. 누군가가 당신에게 그렇게 말하면, 그들은 틀렸습니다.
하나의 보호 층으로는 충분하지 않습니다.
너는 말할 수 없다.
아, CSP를 구현했기 때문에 안전합니다. 내 취약점 목록에서 크로스 사이트 스크립팅을 사용할 수는 없으므로 지금 건너 뛸 수 있습니다.
어쩌면 그것이 어떤 사람들에게는 주어진 것이지만, 이런 식으로 생각하는 것은 쉽습니다. 필자는 프로그래머가 이런 식으로 생각하는 것을 쉽게 발견 할 수있는 한 가지 이유는 너무 많은 코딩이 흑백이거나 0 또는 1, true 또는 false이기 때문이라고 생각합니다. 보안은 그렇게 간단하지 않습니다.
우리는 모두가 웹 개발 여정에서 일찍부터 달려 나가기 시작합니다. 그리고 StackOverflow를보고 그것을 우회하는 방법을 알려주는 답을 찾으십시오.
교차 출하 자원 공유 (CORS, Cross-Origin Resource Sharing)
이런 식으로 보이는 오류를 본 적이 있습니까?
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
당신은 분명히 혼자가 아닙니다. 그리고 나서 당신은 구글 그것, 그리고 누군가가 당신의 모든 문제가 사라질 것 입니다이 확장을 얻을 것을 알려줍니다!
좋아, 맞지?
CORS는 당신을 보호하고, 당신을 해치지 않습니다!
CORS가 어떻게 도움이되는지 설명하기 위해 먼저 쿠키, 특히 인증 쿠키에 대해 이야기 해 봅시다 . 인증 쿠키는 사용자가 로그인했다는 것을 서버에 알리는 데 사용되며 사용자가 요청한 경우 자동으로 해당 서버에 전송됩니다.
Facebook에 로그인하고 인증 쿠키를 사용한다고 가정 해 봅시다. 클릭 bit.ly/r43nugi 하면 당신이 리디렉션됩니다
superevilwebsite.rocks .스크립트는 인증 쿠키를 보내는 superevilwebsite.rocks 클라이언트 측 요청을 만듭니다
facebook.com
.CORS가없는 세계에서는 모르는 사이에 계정을 변경할 수 있습니다. 물론, 그들은 bit.ly/r43nugi 타임 라인에 게시 할 때까지 모든 친구들이 그것을 클릭 한 다음 bit.ly/r43nug 모든 친구들의 타임 라인에 게시한 다음 Facebook의 모든 사용자를 정복하는 사악한 폭스런 방식으로 계속 순환합니다. 세상은에 의해 소비된다
superevilwebsite.rocks �
그러나 CORS 세계에서는 페이스 북이 원산지를 가진 요청 만 facebook.com서버의 데이터를 편집하는 것을 허용합니다.
즉, 교차 출처의 자원 공유를 제한합니다.
다음 물어볼 수도 있습니다 ...
그럼 superevilwebsite.rocks는 facebook.com에서 오는 것처럼 보일 정도로 요청시 원 래 헤더를 변경 할 수 있습니까?
그들은 시도 할 수 있지만 브라우저가 무시하고 실제적인 원점을 사용하기 때문에 작동하지 않습니다.
좋습니다.하지만 superevilwebsite.rocks가 요청을 서버 쪽에서 만든 경우 어떻게해야합니까?
이 경우 CORS를 우회 할 수는 있지만 승차를 위해 인증 쿠키를 보낼 수 없기 때문에 이길 수 없습니다. 이 스크립트는 클라이언트 측 쿠키에 액세스하기 위해 클라이언트 측에서 실행해야합니다.
콘텐츠 보안 정책 (CSP, Content Security Policy)
CSP를 이해하려면 먼저 웹에서 가장 일반적인 취약점 중 하나 인 크로스 사이트 스크립팅 (예 : 다른 약어)을 나타내는 XSS에 대해 이야기해야합니다.
XSS는 악의적 인 사람이 자바 스크립트를 클라이언트 측 코드에 삽입하는 경우입니다. 그렇게 생각 할수 있겠지…
그들이 뭘하려는 건가요? 색상을 빨간색에서 파란색으로 변경 하시겠습니까?
방문중인 웹 사이트의 클라이언트 측 코드에 누군가가 JavaScript를 성공적으로 주입했다고 가정 해 봅시다.
그들은 당신이 가장하는 다른 사이트에 HTTP 요청을 할 수 있습니다.
가능성은 무한합니다.
iframe에서 열 수있는 항목
어떻게 작동합니까?
브라우저의 주소 표시 줄에 링크를 클릭하거나 웹 사이트 URL을 입력하면 브라우저가 GET 요청을합니다. 결국 일부 HTTP 헤더와 함께 HTML을 제공하는 서버로 이동합니다. 어떤 헤더를 수신하는지 궁금하다면 콘솔의 네트워크 탭을 열고 일부 웹 사이트를 방문하십시오.
다음과 같은 응답 헤더가 표시 될 수 있습니다.
content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
이것이 facebook.com 콘텐츠 보안 정책입니다
.
더 쉽게 읽을 수 있도록 다시 포맷 해 봅시다.
content-security-policy:
default-src * data: blob:;
script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';
style-src data: blob: 'unsafe-inline' *;
connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
default-src 명시 적으로 나열되지 않은 다른 모든 CSP 지정 문을 제한합니다.
위의 4 가지보다 CSP 지시문이 더 많습니다. 브라우저는 CSP 헤더를 읽고 해당 지시문을 제공된 HTML 파일 내의 모든 것에 적용합니다. 지시문이 적절히 설정되면 필요한 것만 허용됩니다.
CSP 헤더가 없으면 모든 것이 진행되고 아무 것도 제한되지 않습니다. 어디에서나 볼 수 있는 것은 와일드 카드입니다.
당신은* 무엇이든 대체하는 것이 상상
될 수 있으며 허용 될 것입니다.
HTTPS 또는 HTTP 보안
물론 HTTPS에 대해 들어봤을 것입니다. 어쩌면 당신은 사람들이 말하는 것을 들었을 것입니다 ...
내가 게임을하는 웹 사이트에있는 경우 HTTPS 사용에 신경을 쓰지 않는 이유는 무엇입니까?
아니면 상대방의 말을 들었을 것입니다 ...
귀하의 사이트에 HTTPS가 없으면 미친 것입니다. 2018 년입니다! 다르게 말하는 사람은 신뢰하지 마십시오.
아마 당신은 HTTPS가 아닌 경우 크롬이 귀하의 사이트를 안전하지 않은 것으로 표시한다고 들었을 것입니다.
HTTPS의 핵심은 매우 간단합니다. HTTPS는 암호화되고 HTTP는 암호화되지 않습니다.
민감한 데이터를 전송하지 않는 이유는 무엇입니까?
중간에 남자를 의미하는 다른 두문자어 ... MITM을 준비하십시오.
커피 숍에서 공개 Wi-Fi를 비밀번호없이 사용하는 경우 누군가가 라우터처럼 행동하기가 쉽기 때문에 모든 요청과 응답이 라우터를 통과하게됩니다. 데이터가 암호화되지 않은 경우 원하는 데이터를 원하는대로 수행 할 수 있습니다. HTML, CSS 또는 JavaScript를 브라우저에 보내기 전에 편집 할 수 있습니다. 우리가 XSS에 대해 알고있는 것을 감안할 때 이것이 얼마나 나쁜지 상상할 수 있습니다.
그렇지만 내 컴퓨터와 서버가 어떻게 암호화 / 암호 해독 방법을 알고 있지만이 MITM은 그렇지 않은가요?
SSL (Secure Sockets Layer) 및 최근에는 TLS (Transport Layer Security)가 등장합니다. TLS는 HTTPS에서 사용되는 암호화 기술로 1999 년 SSL을 대신했습니다. 정확히 TLS 작동 방식은이 게시물의 범위를 벗어납니다.
HTTP 엄격 전송 보안 (HSTS)
이것은 매우 간단합니다. 다시 페이스 북의 머리글을 예로 들어 보겠습니다.
max-age 브라우저가 HTTPS를 사용하여 웹 사이트에 액세스하도록 강제하는 것을 기억해야하는 기간을 지정합니다.
이 헤더는 HTTPS를 사용하여 사이트에 액세스 한 경우에만 적용됩니다. HTTP를 통해 사이트에 액세스하면 헤더가 무시됩니다. 그 이유는 간단히 말해서 HTTP는 안전하지 않아서 신뢰할 수 없다는 것입니다.
이것이 실제로 어떻게 도움이되는지 자세히 설명하기 위해 페이스 북 예제를 사용합시다.
처음 facebook.com 액세스 하는 경우 HTTPS가 HTTP보다 안전하므로 HTTPS를 통해 액세스합니다
.
브라우저가 HTML을 수신하면 위의 헤더를 수신하여 브라우저에 향후 요청을 위해 HTTPS로 강제 리디렉션하도록 지시합니다.
한 달 후, 누군가가 당신에게 HTTP를 사용하여 페이스 북에 대한 링크를 보내고http://facebook.com
그것을 클릭합니다.
한 달이 max-age 지시문에 지정된 15552000 초보다 짧기 때문에 브라우저는 요청을 HTTPS로 전송하여 잠재적 인 MITM 공격을 방지합니다.
