왜 자바 스크립트가 궁금할까요 javascript가 왜 그렇게 중요합니까

CORS, CSP, HSTS 및 모든 웹 보안 약어에 대한 웹 개발자 입문서!

웹 보안에 대해 배워야하는 이유는 다음과 같습니다.

• 귀하는 귀하의 개인 데이터가 유출되는 것을 걱정하는 우려되는 사용자입니다.
• 웹 앱을 더 안전하게 만들고 싶어하는 우려되는 웹 개발자입니다.
• 당신은 직업에 지원하는 웹 개발자이고 면접관이 웹 보안에 대해 질문 할 때 준비하고 싶어합니다.

등등.

이 게시물은 이해하기 쉽지만 여전히 정확한 방식으로 일반적인 웹 보안 약어를 설명합니다.

그 전에 보안의 몇 가지 핵심 개념을 이해해야합니다.

보안의 두 가지 핵심 개념

아무도 100 % 안전하지 않습니다.

해킹으로부터 100 % 보호된다는 개념은 없습니다. 누군가가 당신에게 그렇게 말하면 그들은 틀린 것입니다.

하나의 보호 계층으로는 충분하지 않습니다.

당신은 말할 수 없습니다 ...

아, CSP를 구현했기 때문에 안전합니다. 지금은 불가능하므로 취약점 목록에서 교차 사이트 스크립팅을 제거 할 수 있습니다.

그것은 어떤 사람들에게 주어진 것일 수도 있지만, 이런 식으로 생각하는 자신을 찾는 것은 쉽습니다. 프로그래머가 이런 식으로 쉽게 생각할 수있는 한 가지 이유는 코딩의 대부분이 흑백, 0 또는 1, 참 또는 거짓이기 때문이라고 생각합니다. 보안은 그렇게 간단하지 않습니다.

우리는 모두가 웹 개발 여정의 초기 단계에서 마주 치는 것으로 시작하겠습니다. 그런 다음 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.

당신은 확실히 혼자가 아닙니다. 그런 다음 Google을 검색하면 누군가가 모든 문제를 해결할 수있는이 확장 프로그램을 가져 오라고합니다!

좋아요, 그렇죠?

CORS는 당신을 해치지 않고 보호하기 위해 존재합니다!

CORS가 어떻게 도움이되는지 설명하기 위해 먼저 쿠키, 특히 인증 쿠키에 대해 이야기하겠습니다 . 인증 쿠키는 사용자가 로그인되었음을 서버에 알리는 데 사용되며 해당 서버에 대한 요청과 함께 자동으로 전송됩니다.

Facebook에 로그인되어 있고 인증 쿠키를 사용한다고 가정 해 보겠습니다. 당신은 당신 bit.ly/r43nugi을 리디렉션하는 클릭 합니다 superevilwebsite.rocks. 내부 스크립트 는 인증 쿠키를 보내는 superevilwebsite.rocks클라이언트 측 요청을 facebook.com합니다!

CORS가없는 세상에서는 사용자가 모르게 계정을 변경할 수 있습니다. 물론, 그들이 bit.ly/r43nugi당신의 타임 라인에 게시 하고 당신의 모든 친구들이 그것을 클릭 할 때까지, 그들은 당신의 bit.ly/r43nugi모든 친구들의 타임 라인에 게시 하고, 그주기는 페이스 북의 모든 사용자를 정복하는 사악한 폭 우선 계획으로 계속됩니다. 그리고 세상은 superevilwebsite.rocks. ?

그러나 CORS 세계에서 Facebook은 원본이있는 요청 만 facebook.com서버에서 데이터를 편집 하도록 허용 합니다. 즉, 교차 출처 리소스 공유를 제한합니다. 그런 다음 질문 할 수 있습니다.

superevilwebsite.rocks는 요청에 따라 원본 헤더를 변경하여 facebook.com에서 오는 것처럼 보이게 할 수 있습니까?

시도 할 수는 있지만 브라우저가이를 무시하고 실제 출처를 사용하기 때문에 작동하지 않습니다.

좋습니다.하지만 superevilwebsite.rocks가 서버 측에서 요청을했다면 어떻게 될까요?

이 경우 CORS를 우회 할 수 있지만 승차를 위해 인증 쿠키를 보낼 수 없기 때문에 이길 수 없습니다. 클라이언트 측 쿠키에 액세스하려면 스크립트를 클라이언트 측에서 실행해야합니다.

콘텐츠 보안 정책 (CSP)

CSP를 이해하려면 먼저 웹에서 가장 일반적인 취약점 중 하나 인 XSS에 대해 이야기해야합니다. XSS는 크로스 사이트 스크립팅을 의미합니다 (예, 다른 약어).

XSS는 악의적 인 사람이 클라이언트 측 코드에 JavaScript를 삽입하는 경우입니다. 그렇게 생각 할수 있겠지…

그들이 뭘하려는 건가요? 빨간색에서 파란색으로 색상을 변경 하시겠습니까?

누군가 당신이 방문하는 웹 사이트의 클라이언트 측 코드에 JavaScript를 성공적으로 주입했다고 가정 해보자.

그들이 악의적 인 행동을 할 수 있습니까?

• 그들은 당신을 가장하여 다른 사이트에 HTTP 요청을 할 수 있습니다.
• 그들은 약간 다른 악의적 인 특성을 가지고있는 웹 사이트와 동일하게 보이는 웹 사이트로 사용자를 보내는 앵커 태그를 추가 할 수 있습니다.
• 인라인 JavaScript로 스크립트 태그를 추가 할 수 있습니다.
• 원격 자바 스크립트 파일을 어딘가에 가져 오는 스크립트 태그를 추가 할 수 있습니다.
• 페이지를 덮고 암호를 입력하라는 웹 사이트의 일부처럼 보이는 iframe을 추가 할 수 있습니다.

가능성은 무한합니다.

CSP는 다음을 제한하여 이러한 일이 발생하지 않도록합니다.

• 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:* //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:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

이제 지시문을 분해 해 보겠습니다.

• default-src 명시 적으로 나열되지 않은 다른 모든 CSP 지시문을 제한합니다.
• script-src로드 할 수있는 스크립트를 제한합니다.
• style-src 로드 할 수있는 스타일 시트를 제한합니다.
• connect-src fetch, XHR, ajax 등의 스크립트 인터페이스를 사용하여로드 할 수있는 URL을 제한합니다.

위에 표시된 네 가지보다 더 많은 CSP 지시문이 있습니다. 브라우저는 CSP 헤더를 읽고 제공된 HTML 파일 내의 모든 것에 해당 지시문을 적용합니다. 지시문이 적절하게 설정되면 필요한 것만 허용합니다.

CSP 헤더가 없으면 모든 것이 진행되고 아무것도 제한되지 않습니다. 당신이 볼 수있는 모든 곳 *은 와일드 카드입니다. *무엇이든 교체 하는 것을 상상할 수 있으며 허용됩니다.

HTTPS 또는 HTTP 보안

확실히 HTTPS에 대해 들어 보셨을 것입니다. 어떤 사람들이 ...

게임을하는 웹 사이트에서 HTTPS 사용에 관심이있는 이유는 무엇입니까?

아니면 상대방의 말을 들었을 수도 있습니다.

사이트에 HTTPS가 없으면 미쳤습니다. 2018 년입니다! 달리 말하는 사람을 믿지 마십시오.

이제 Chrome이 HTTPS가 아닌 경우 사이트를 안전하지 않은 것으로 표시한다고 들었을 것입니다.

핵심에서 HTTPS는 매우 간단합니다. HTTPS는 암호화되고 HTTP는 암호화되지 않습니다.

그렇다면 민감한 데이터를 보내지 않는데 왜 이것이 중요할까요?

또 다른 약어를 준비하십시오.… MITM은 Man in the Middle을 의미합니다.

커피 숍에서 비밀번호없이 공용 Wi-Fi를 사용하는 경우, 누군가가 라우터처럼 행동하기가 매우 쉬워서 모든 요청과 응답이이를 통과합니다. 데이터가 암호화되지 않은 경우 원하는 모든 작업을 수행 할 수 있습니다. HTML, CSS 또는 JavaScript가 브라우저에 도착하기 전에 편집 할 수 있습니다. 우리가 XSS에 대해 알고있는 것을 감안할 때 이것이 얼마나 나쁠 수 있는지 상상할 수 있습니다.

좋아,하지만 내 컴퓨터와 서버가 암호화 / 복호화하는 방법을 어떻게 알고 있지만이 MITM은 그렇지 않습니까?

That’s where SSL (Secure Sockets Layer) and more recently, TLS (Transport Layer Security) come in. TLS took over for SSL in 1999 as the encryption technology used within HTTPS. Exactly how TLS works is outside of the scope of this post.

HTTP Strict-Transport-Security (HSTS)

This one is pretty straightforward. Let’s use Facebook’s header as an example again:

strict-transport-security: max-age=15552000; preload

• max-age specifies how long a browser should remember to force the user to access a website using HTTPS.
• preload is not important for our purposes. It is a service hosted by Google and not part of the HSTS specification.

This header only applies if you accessed the site using HTTPS. If you accessed the site via HTTP, the header is ignored. The reason is that, quite simply, HTTP is so insecure that it can’t be trusted.

Let’s use the Facebook example to further illustrate how this is helpful in practice. You are accessing facebook.com for the first time, and you know HTTPS is safer than HTTP, so you access it over HTTPS, //facebook.com. When your browser receives the HTML, it receives the header above which tells your browser to force-redirect you to HTTPS for future requests. One month later, someone sends you a link to Facebook using HTTP, //facebook.com, and you click on it. Since one month is less than the 15552000 seconds specified by the max-age directive, your browser will send the request as HTTPS, preventing a potential MITM attack.

Closing Thoughts

Web security is important no matter where you are in your web development journey. The more you expose yourself to it, the better off you will be. Security is something that should be important to everyone, not just the people who have it explicitly named in their job title! ?