루니프의 짤막보안강의

내 컴퓨터에서는 잘 실행되는데 배포 서버에서만 오류가 발생한 적이 있나요? 이때는 소스 코드만 보지 말고, 두 환경에 실제로 전달된 파일이 같은지도 확인해야 합니다.이번 자료의 원문 제목은 「파일 해시」입니다. 다만 제공된 기록에는 어떤 파일을 비교했는지, 개발자 PC와 서버가 어떻게 달랐는지, 파일 해시가 실제로 어떻게 사용됐는지가 적혀 있지 않습니다. 따라서 아래 내용은 사례의 결과를 단정하는 설명이 아니라, 이 주제를 확인하기 위한 일반적인 기준입니다.파일 해시는 환경을 맞추는 도구라기보다, 비교하려는 파일이 정말 같은지 확인하는 단서입니다.파일 해시란 무엇인가먼저 파일부터 생각해 보겠습니다. 파일 이름이 같아도 내용이 다를 수 있습니다. 다른 경로에서 복사했거나, 배포 과정에서 파일이 바뀌었을 수..

출처: https://www.dailysecu.com/news/articleView.html?idxno=208773로그인한 뒤 한 서비스에서 확인한 고객번호를 다른 조회 서비스에 사용할 수 있다면, 한 API의 취약점만 점검해서는 충분하지 않을 수 있습니다. 서비스 사이의 업무 흐름이 어떻게 이어지는지까지 확인해야 하기 때문입니다.제공된 뉴스 분석은 금융권 연쇄 침해사고의 핵심을 새로운 AI 기술 자체보다 외부 접점과 서버 측 인증·인가 검증의 빈틈이 정보유출로 연결된 점에서 찾습니다. AI는 반복 점검을 빠르게 해 주지만, 실제 업무에서 한 요청이 다음 요청의 권한과 어떤 관계를 갖는지는 사람이 확인해야 합니다.API와 인증·인가부터 이해하기애플리케이션 프로그래밍 인터페이스(Application Pro..

로그인이나 파일 보호에 사용하는 RSA 키를 만들 때, 서로 다른 키가 같은 소수를 다시 사용하면 어떻게 될까요? 결론부터 말하면 암호 알고리즘의 수식이 곧바로 틀렸다는 뜻이 아니라, 키를 만드는 구현이 약점을 만들 수 있다는 뜻입니다.제공된 사례 기록은 RSA 키 생성에서 소수 재사용이 발생하는 상황과, 알고리즘 자체의 안전성과 구현상의 실패를 구분해야 한다는 점을 다룹니다. 다만 구체적인 원인, 공격 조건, 실제 피해 여부는 기록에 포함되어 있지 않습니다.RSA 키는 왜 소수와 관련이 있을까?RSA 암호(Rivest–Shamir–Adleman, RSA)는 공개키와 개인키를 사용하는 암호 방식입니다. 일반적인 RSA 구조에서는 서로 다른 두 소수를 바탕으로 공개키와 개인키를 계산합니다.공개키에는 보통 ..

검색 조건에 특수문자를 넣었더니 화면에 갑자기 내부 오류가 나타났다면 어떻게 봐야 할까요? 이 현상만으로 공격 성공을 단정할 수는 없습니다. 하지만 입력값 처리와 오류 응답을 두 갈래로 나누어 점검해야 합니다.이 글은 SQL 인젝션(SQL Injection, 약칭 SQLi)이 무엇인지 먼저 설명한 뒤, 오류 메시지 노출을 왜 별도로 확인해야 하는지 정리합니다. 제공된 사례에서는 실제 공격 성공, 오류 내용, 피해 범위가 확인되지 않았다는 점도 함께 구분합니다.핵심은 오류를 숨기는 데 그치지 않고, 검색값이 질의 구조를 바꾸지 못하는지와 오류 응답이 내부 정보를 드러내지 않는지를 따로 확인하는 것입니다.검색 기능에서 먼저 이해할 흐름검색 기능은 보통 사용자가 입력한 조건을 서버로 보내고, 서버가 그 조건에..

출처: https://www.securityweek.com/exploitation-hits-rejetto-hfs-vulnerability-discovered-by-ai/로그인 뒤에도 매번 비밀번호를 다시 입력하지 않는 이유는 무엇일까요? 웹 서비스는 보통 브라우저에 세션 쿠키(session cookie)를 저장하고, 다음 요청에서 이 쿠키를 확인해 로그인 상태를 이어 갑니다. 쿠키가 서버가 만든 것인지 확인하는 과정에는 서명 키가 쓰일 수 있습니다.그런데 이 서명 키를 예측 가능한 난수로 만들면 문제가 달라집니다. Rejetto HTTP File Server(HFS)의 CVE-2026-61500 사례에서는 공격자가 난수 생성기의 상태와 세션 쿠키 서명 키를 복구한 뒤 관리자 쿠키를 위조할 수 있었습니다...

결제 QR을 한 번 사용한 뒤 같은 QR을 다시 보여 줬는데도 결제가 승인된다면 어떻게 해야 할까요? 핵심은 QR 화면 자체가 아니라, 결제 요청이 이미 사용된 요청인지 서버가 확인하는가에 있습니다.이 글에서는 결제 요청에 붙는 Nonce와, 한 번 사용된 값을 다시 거부하는 검증 원리를 설명합니다. 다만 제공된 사례 기록만으로 실제 승인 결과나 구체적인 구현 방식까지 확인할 수는 없습니다.먼저 알아둘 것: 결제 요청과 QR모바일 결제에서 QR은 사용자가 결제 정보를 전달하는 한 가지 방법입니다. 결제 시스템은 QR을 통해 전달된 요청을 확인한 뒤 승인 여부를 판단합니다.여기서 중요한 질문은 “QR을 다시 보여 줬는가?”보다 “같은 결제 요청을 새 요청으로 잘못 처리하지 않는가?”입니다. 같은 요청을 여..