본문 바로가기
빌드노트 검색

빌드노트

웹 보안

웹 보안 카테고리의 글입니다.

글 검색

글 목록

총 48개의 글

  1. 팝업은 열려 있는데 window.open 참조의 closed는 true다

    팝업이 살아 있는데 반환 참조의 closed가 true가 되는 COOP 조건을 두 loopback 출처에서 비교했다. 실제 종료와 참조 분리를 구분하고, 양쪽 문서의 응답 헤더·출처·창 통신 요구를 확인하는 방법을 설명한다.

  2. 검색어를 보여주는 코드에 innerHTML을 쓰면 생기는 일

    검색어를 innerHTML로 출력하면 태그가 화면 요소가 된다. 실제 브라우저에서 요소 수와 원문 보존을 비교하고, 평문은 textContent로 표시하되 기존 아이콘을 지킬 출력 위치와 HTML 정제가 필요한 별도 경로를 구분한다.

  3. 쿠키가 저장됐는데 다른 경로에서 로그인이 풀리면 Path를 확인한다

    세션 쿠키가 저장돼 있어도 Path가 요청 URL에 맞지 않으면 서버에는 전송되지 않는다. 새 브라우저 컨텍스트에서 /account와 / 쿠키의 저장·요청·서버 수신을 비교하고, 기본 Path와 변경 뒤 중복 쿠키까지 확인해 적용 경로를 고르는 방법을 설명한다.

  4. 서버에는 200인데 쿠키를 넣은 fetch는 응답을 못 읽는다

    서버의 GET 200과 브라우저의 응답 읽기 성공은 다르다. 두 loopback origin에서 credentials와 CORS 응답 헤더의 8개 조합, 쿠키 삭제 뒤 2개 조건을 실제 비교하고 정확한 프런트 origin과 Allow-Credentials를 확인할 위치를 설명한다.

  5. frame-ancestors를 meta에 썼는데 iframe 차단이 안 된다

    frame-ancestors는 HTML meta로 전달하면 적용되지 않는다. 두 loopback origin에서 meta·HTTP 헤더·부모 허용 정책을 비교하고, load 이벤트나 준비 메시지의 유무만으로 삽입 차단을 판단하면 틀리는 이유를 확인한다.

  6. 응답에는 ETag가 있는데 headers.get("ETag")는 null이다

    교차 출처 fetch의 본문은 읽히는데 ETag만 null일 때는 전송과 노출을 나눠 확인한다. 두 loopback 포트의 실제 Chromium에서 노출 없음·명시적 ETag 노출·동일 출처를 비교하고 실제 응답의 Expose-Headers를 수정할 위치를 설명한다.

  7. Node.js HMAC 값이 다르다면 hex 키를 문자열로 넘겼는지 확인한다

    Node.js createHmac에 hex 키 문자열을 그대로 넘기면 글자들의 UTF-8 바이트가 키가 된다. 같은 메시지와 직접 지정한 바이트 배열로 HMAC을 대조하고, 잘못된 hex가 잘리는 동작을 확인해 디코딩 전 검증을 적용한다. digest의 출력 인코딩과 키의 표현도 구분한다.

  8. Set-Cookie는 보이는데 __Host- 쿠키가 저장되지 않는다

    Set-Cookie가 보여도 __Host- 속성 계약을 어기면 쿠키 저장은 거절된다. 새 Chromium 컨텍스트에서 Path·Domain·Secure 조건별 저장과 다음 요청 헤더를 비교하고, 일반 Path 전송 제한 및 localhost 예외와 구분해 확인할 설정을 설명한다.

  9. 원본 키와 salt가 같은데 HKDF 결과가 다르다면 info를 본다

    HKDF는 원본 키와 salt가 같아도 info가 다르면 다른 키를 만들 수 있다. 합성 입력으로 용도 문자열·빈 info·줄바꿈·인코딩 차이를 비교하고, Node hkdfSync와 WebCrypto deriveBits에 같은 바이트와 출력 길이를 적용해 대조한다.

  10. Node.js timingSafeEqual이 false 대신 길이 오류를 던질 때

    Node.js timingSafeEqual은 같은 길이의 다른 값에는 false를 반환하지만, 바이트 길이가 다르면 예외를 던진다. LAB1 비교를 한 세션에서 이어 실행하며 UTF-8 변환 뒤 길이를 확인하고 잘못된 입력을 명시적으로 거부하는 위치를 설명한다.

  11. PUBLIC KEY PEM을 WebCrypto에 넣었더니 DataError가 난다

    PUBLIC KEY PEM을 UTF-8 바이트로 바꾸는 것과 SPKI DER로 디코딩하는 것은 다르다. 같은 합성 RSA 키에서 import 실패·성공과 원문·변조 서명 검증을 비교하고, RSA PUBLIC KEY의 PKCS#1 구조를 라벨만 바꿔 가져올 수 없는 이유를 설명한다.

  12. CSP 허용 목록을 넓혀도 다른 헤더의 차단은 남는다

    프록시와 앱이 CSP를 각각 보내면 뒤의 허용 목록을 넓혀도 다른 정책의 차단은 남는다. 격리 브라우저의 9개 loopback 비교에서 헤더 순서·각 단독 정책·Report-Only와 요청 및 실행 표식을 확인하고, 실제 모든 강제 정책의 생성 위치를 찾는 방법을 설명한다.