웹 보안은 종종 프론트 엔드 개발자가 간과하는 주제입니다. 웹 사이트의 품질을 평가할 때 종종 성능, SEO 친 화성 및 접근성과 같은 메트릭을 보고 악의적인 공격을 견딜 수 있는 웹 사이트의 용량은 종종 레이더에 해당합니다. 

민감한 사용자 데이터가 서버 측에 저장되어 있지만 백엔드 개발자는 서버를 보호하기 위해 상당한 조치를 취해야 하지만 결국에는 데이터를 보호하는 책임은 백엔드와 프런트 엔드간에 공유됩니다. 

중요한 데이터는 백엔드웨어 하우스에 안전하게 잠길 수 있지만 프런트 엔드에는 키를 현관에 고정 시키는 것이 있으며 이를 훔치는 것이 가장 쉬운 방법입니다.

https://hackernoon.com/10-security-tips-for-frontend-developers-oi4624ld 

"사용자 데이터 보안에 대한 책임은 백엔드와 프론트 엔드간에 공유됩니다. " 

악의적 인 사용자가 프론트 엔드 응용 프로그램을 손상 시키기 위해 취할 수 있는 여러 가지 공격 경로가 있지만 다행히도 제대로 구성된 응답 헤더 몇 개를 사용하고 좋은 개발 방법을 따르면 이러한 공격의 위험을 크게 줄일 수 있습니다. 

이 기사에서는 웹 애플리케이션의 보호를 향상 시키기 위해 할 수 있는 10 가지 쉬운 작업을 다룰 것입니다.

결과 측정 

웹 사이트 보안을 개선하기 전에 변경 사항의 효과에 대한 피드백을 받는 것이 중요합니다. "좋은 개발 관행"을 구성하는 것을 수량화 하는 것은 어려울 수 있지만 보안 헤더의 강도는 매우 정확하게 측정 될 수 있습니다. 

Lighthouse를 사용하여 성능, SEO 및 접근성 점수를 얻는 것과 마찬가지로, SecurityHeaders.com을 사용하여 현재 응답 헤더를 기반으로 보안 점수를 얻을 수 있습니다. 불완전한 점수의 경우 점수를 향상 시키고 결과적으로 보안을 강화하는 방법에 대한 팁을 제공합니다.

SecurityHeaders가 우리에게 줄 수 있는 최고 점수는“A +”이며, 항상 목표로 삼아야 합니다.

응답 헤더에 대한 참고 사항 

응답 헤더를 다루는 것은 백엔드의 작업 이었지만 오늘날에는 웹 애플리케이션을“Zeit”또는“Netlify”와 같은“서버 없는”클라우드 플랫폼에 배포하고 적절한 응답 헤더를 반환하도록 구성하는 것이 프런트 엔드 책임이 됩니다. 

클라우드 호스팅 제공 업체가 응답 헤더와 작동하는 방식을 배우고 적절하게 구성하십시오.

보안 조치 

1. 강력한 콘텐츠 보안 정책 사용(content security policy) 

사운드 컨텐츠 보안 정책 (CSP)은 프론트 엔드 애플리케이션의 안전을 위한 초석입니다. CSP는 XSS (Cross-Site Scripting) 및 클릭 재킹 (clickjacking)을 포함하여 특정 유형의 코드 삽입 공격을 탐지하고 완화하기 위해 브라우저에 도입 된 표준입니다.

강력한 CSP는 잠재적으로 유해한 인라인 코드 실행을 비활성화하고 외부 리소스가 로드 되는 도메인을 제한 할 수 있습니다. "Content-Security-Policy"헤더를 세미콜론으로 구분 된 지시문 목록으로 설정하여 CSP를 활성화 할 수 있습니다. 

웹 사이트에서 외부 리소스에 액세스 할 필요가 없는 경우 헤더의 시작 값은 다음과 같습니다.

Content-Security-Policy: default-src 'none'; script-src 'self'; img-src 'self'; style-src 'self'; connect-src 'self';

여기서는 script-src, img-src, style-src 및 connect-src 지시문을 self로 설정하여 모든 스크립트, 이미지, 스타일 시트 및 페치 호출이 각각 HTML 문서가 제공되는 동일한 원점으로 제한되어야 함을 나타냅니다. . 

명시 적으로 언급되지 않은 다른 CSP 지시문은 default-src 지시문에 지정된 값으로 대체됩니다. 기본 동작이 모든 URL에 대한 연결을 거부하는 것임을 나타내려면 "없음"으로 설정합니다.

그러나 요즘에는 웹 애플리케이션이 거의 포함되어 있지 않기 때문에 Google Fonts 또는 AWS S3 버킷의 도메인과 같이 신뢰할 수 있는 다른 도메인을 허용하도록 이 헤더를 조정하고 싶을 때 항상 시작하는 것이 좋습니다. 가장 엄격한 정책을 취하고 필요할 경우 나중에 완화하십시오.

MDN 웹 사이트에서 CSP 지침의 전체 목록을 찾을 수 있습니다.

2. XSS 보호 모드를 활성화합니다 

사용자 입력에서 악성 코드가 삽입되면 브라우저에 "X-XSS-Protection": "1; mode = block"header를 제공하여 응답을 차단하도록 지시 할 수 있습니다.

대부분의 최신 브라우저에서는 XSS 보호 모드가 기본적으로 활성화되어 있지만 콘텐츠 보안 정책을 사용하여 인라인 JavaScript 사용을 비활성화 할 수 있지만 X-XSS-Protection 헤더를 포함하여 오래된 브라우저의 보안을 강화하는 것이 좋습니다. CSP 헤더를 지원하지 않습니다.

3. 클릭 재킹 공격을 방지하기 위해 iframe 포함을 비활성화 합니다. 

클릭 재킹은 웹 사이트 A의 사용자가 웹 사이트 B에서 일부 작업을 수행하도록 속이는 공격입니다.이를 위해 악의적 인 사용자가 웹 사이트 B를 보이지 않는 iframe에 삽입 한 다음 웹 사이트 A의 의심 없는 사용자 커서 아래에 배치합니다. 웹 사이트 A에서 요소를 클릭한다고 생각하거나 실제로 웹 사이트 B에서 무언가를 클릭합니다.

웹 사이트를 프레임으로 렌더링 하는 것을 금지하는 "X-Frame-Options"헤더를 제공하여 이러한 공격으로부터 보호 할 수 있습니다.

"X-Frame-Options": "DENY"

또는 부모님이 iframe에 페이지를 포함 할 수 있는지 여부를 보다 세부적으로 제어 할 수 있는 '프레임 조상'CSP 지시문을 사용할 수 있습니다.

4. 브라우저 기능 및 API에 대한 액세스 제한 

올바른 보안 관행의 일부는 웹 사이트를 올바르게 사용하는 데 필요하지 않은 것에 대한 액세스를 제한하는 것입니다. 

CSP를 사용하여 이 원칙을 이미 적용하여 웹 사이트에 연결할 수 있는 도메인 수를 제한했지만 브라우저 기능에도 적용 할 수 있습니다. 

'기능 정책'헤더를 사용하여 애플리케이션에 필요하지 않은 특정 기능 및 API에 대한 액세스를 거부하도록 브라우저에 지시 할 수 있습니다.

"Feature-Policy"를 세미콜론으로 구분 된 일련의 규칙으로 설정합니다. 여기서 각 규칙은 기능의 이름이며 그 뒤에 정책 이름이 옵니다.

"Feature-Policy": "accelerometer 'none'; ambient-light-sensor 'none'; autoplay 'none'; camera 'none'; encrypted-media 'none'; fullscreen 'self'; geolocation 'none'; gyroscope 'none'; magnetometer 'none'; microphone 'none'; midi 'none'; payment 'none';  picture-in-picture 'none'; speaker 'none'; sync-xhr 'none'; usb 'none'; vr 'none';"

"Smashing Magazine"에는 "기능 정책"에 대해 자세히 설명하는 훌륭한 기사가 있지만 대부분 사용하지 않는 모든 기능에 대해 "없음"으로 설정하려고 합니다.

5. 리퍼러 값을 누설하지 마십시오 

귀하의 웹 사이트에서 다른 곳으로 이동하는 링크를 클릭하면 대상 웹 사이트는 귀하의 웹 사이트에서 "추천자"헤더로 마지막 위치의 URL을 받습니다. 이 URL에는 세션 토큰 및 사용자 ID와 같은 민감한 데이터와 세미 민감한 데이터가 포함될 수 있으며 노출해서는 안됩니다.

"추천자"값의 유출을 방지하기 위해 "참조 자 정책"헤더를 참조 자 없음으로 설정했습니다.

"Referrer-Policy": "no-referrer"

이 값은 대부분의 경우에 적합하지만 응용 프로그램 논리에 따라 리퍼러를 유지해야 하는 경우 Scott Helme의 이 기사에서 가능한 모든 헤더 값을 분류하고 적용 시기를 확인하십시오.

6. 사용자 입력에 따라 innerHTML 값을 설정하지 마십시오 

악성 코드가 웹 사이트에 삽입되는 사이트 간 스크립팅 공격은 다양한 DOM API를 통해 발생할 수 있지만 가장 많이 사용되는 것은 HTML입니다.

필터링 되지 않은 사용자 입력에 따라 innerHTML을 설정해서는 안됩니다. 사용자가 직접 조작 할 수 있는 모든 값은 입력 필드의 텍스트, URL의 매개 변수 또는 로컬 스토리지 항목이 이스케이프 처리되어야 합니다. 

이상적으로는 HTML 출력이 완전히 생성되지 않도록 innerHTML 대신 texttext를 사용하십시오. 

사용자에게 리치 텍스트 편집을 제공해야 하는 경우 블랙리스트 대신 화이트 리스트를 사용하는 잘 설정된 라이브러리를 사용하여 허용되는 HTML 태그를 지정하십시오.

불행히도, innerHTML은 DOM API의 유일한 약점이 아니며 XSS 주입에 취약한 코드는 여전히 탐지하기 어려울 수 있습니다. 따라서 항상 인라인 코드 실행을 허용하지 않는 엄격한 컨텐츠 보안 정책을 유지하는 것이 중요합니다.

미래에는 모든 DOM 기반 사이트 간 스크립팅 공격을 방지하기 위한 새로운 "신뢰할 수 있는 유형"사양을 계속 지켜봐야 할 것입니다.

7. UI 프레임 워크 사용 

React, Vue 및 Angular와 같은 최신 UI 프레임 워크에는 우수한 보안 수준이 내장되어 있으며 XSS 공격의 위험을 크게 제거 할 수 있습니다. 

HTML 출력을 자동으로 인코딩하고 XSS에 민감한 DOM API를 사용할 필요성을 줄이며, dangerouslySetInnerHTML과 같이 잠재적으로 위험한 방법에 대해 명확하고 신중한 이름을 지정합니다.

8. 의존성을 최신 상태로 유지 

node_modules 폴더 내부를 살펴보면 웹 응용 프로그램이 수백 (수천이 아닌 경우)의 의존성으로 구성된 레고 퍼즐임을 확인할 수 있습니다. 

이러한 종속성에 알려진 보안 취약점이 없는지 확인하는 것은 웹 사이트의 전반적인 보안에 매우 중요합니다.

의존성을 안전하게 유지하고 최신 상태로 유지하는 가장 좋은 방법은 개발 프로세스의 일부로 취약점 검사를 수행하는 것입니다. 이를 위해 "Dependabot"및 "Snyk"와 같은 도구를 통합하여 오래되었거나 잠재적으로 취약한 종속성에 대한 풀 요청을 작성하고 수정 사항을 더 빨리 적용 할 수 있습니다.

9. 타사 서비스를 추가하기 전에 두 번 생각하십시오 

Google Analytics, Intercom, Mixpanel 및 기타 수백 개의 타사 서비스는 비즈니스 요구에 "한 줄의 코드"솔루션을 제공 할 수 있습니다. 동시에 타사 서비스가 손상되면 웹 사이트가 손상되기 때문에 웹 사이트를 보다 취약하게 만들 수 있습니다.

타사 서비스를 통합하기로 결정한 경우 해당 서비스가 정상적으로 작동하도록 허용하는 가장 강력한 CSP 정책을 설정해야 합니다. 널리 사용되는 대부분의 서비스는 필요한 CSP 지시문을 문서화 했으므로 지침을 따르십시오.

Google 태그 관리자, 세그먼트 또는 조직 내 모든 사람이 더 많은 타사 서비스를 통합 할 수 있는 기타 도구를 사용할 때는 특히 주의해야 합니다. 

이 도구에 액세스 할 수 있는 사람은 추가 서비스 연결의 보안 영향을 이해하고 개발 팀과 이상적으로 논의해야 합니다.

10. 타사 스크립트에 하위 리소스 무결성 사용 

사용하는 모든 타사 스크립트에 대해 가능하면 무결성 속성을 포함해야 합니다. 브라우저에는 '하위 리소스 무결성'기능이있어로드중인 스크립트의 암호화 해시의 유효성을 검사하고 변조 되지 않았는지 확인할 수 있습니다.

이렇게 하면 스크립트 태그가 다음과 같이 보일 수 있습니다

<script src="https://example.com/example-framework.js"
        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux..."
        crossorigin="anonymous"></script>

이 기술은 타사 라이브러리에는 유용하지만 타사 서비스에는 덜 유용하다는 점을 분명히 밝힐 가치가 있습니다. 대부분의 경우 타사 서비스 용 스크립트를 추가 할 때 해당 스크립트는 다른 종속 스크립트를 로드 하는 데만 사용됩니다. 

언제든지 수정할 수 있기 때문에 종속 스크립트의 무결성을 확인할 수 없으므로 이 경우 엄격한 콘텐츠 보안 정책으로 돌아 가야 합니다.

결론 

브라우징 경험 저장은 최신 웹 응용 프로그램의 중요한 부분이며, 사용자는 개인 데이터를 안전하게 보호해야 합니다. 이 데이터는 백엔드에 저장되지만 이를 보호하는 책임은 클라이언트 측 응용 프로그램에도 적용됩니다.

악의적인 사용자가 활용할 수 있는 UI 우선 공격에는 여러 가지 변형이 있지만 이 문서에 제공된 권장 사항을 따르면 공격에 대한 방어 가능성을 크게 높일 수 있습니다.