홈페이지 해킹 방지, SQL 인젝션부터 파일 업로드까지 체크리스트 7가지

홈페이지 해킹 방지, SQL 인젝션부터 파일 업로드까지 체크리스트 7가지

---

"우리 홈페이지는 작고 유명하지 않으니까 해킹당할 일은 없겠지" — 이렇게 생각하고 계신다면 오늘 이 글을 꼭 끝까지 읽어보시길 권합니다. 2026년 8월 현재, 웹 공격의 절대다수는 사람이 직접 표적을 골라서 벌이는 게 아니라 자동화된 봇이 인터넷 전체를 무작위로 스캔하면서 취약점이 발견되는 사이트를 순서 없이 공격하는 방식으로 이뤄지고 있습니다. 즉 방문자가 하루 10명인 홈페이지든, 대기업 공식 사이트든 봇의 스캔 대상에서는 차이가 없다는 뜻이죠.

이 글에서는 SQL 인젝션, XSS(크로스사이트 스크립팅), 파일 업로드 취약점, 계정 탈취라는 대표적인 웹 공격 4가지의 원리를 비전공자도 이해할 수 있게 풀어드리고, 실제로 홈페이지를 운영하거나 관리하는 입장에서 "우리 사이트는 이게 되어 있나"를 스스로 점검할 수 있는 체크리스트 7가지를 단계별로 정리했습니다. 개발자가 아니어도 괜찮습니다. 외주 개발사와 소통할 때, 혹은 담당자에게 확인 요청을 할 때 그대로 활용할 수 있도록 실무 중심으로 구성했습니다.

OWASP(Open Web Application Security Project)라는 국제 웹 보안 표준 목록을 기준으로 설명하는 만큼, 이 글 하나만 제대로 읽어두셔도 웹 보안의 핵심 뼈대를 이해하는 데는 충분할 것입니다.

준비물·전제조건 — 시작 전에 알아둘 것

이 체크리스트를 활용하기 위해 전문적인 보안 지식이나 별도의 툴이 필요한 것은 아닙니다. 관리자 페이지 접근 권한과 개발 담당자 혹은 외주사와의 소통 채널만 있으면 충분히 점검을 시작할 수 있습니다.

먼저 준비하면 좋은 것들을 정리해보겠습니다.

특히 강조하고 싶은 부분은 테스트는 반드시 운영 서버가 아닌 별도 환경에서 진행해야 한다는 점입니다. 보안 점검 과정에서 실수로 실서비스에 영향을 주는 사례가 은근히 많기 때문에, 스테이징 서버가 없다면 이번 기회에 구축을 검토해보시는 것도 좋습니다.

지식적인 측면에서는 "우리 홈페이지가 어떤 언어·프레임워크로 만들어졌는지", "DB는 어떤 종류를 쓰는지" 정도만 파악하고 있어도 충분합니다. 이 정보는 담당 개발자에게 물어보면 바로 확인할 수 있습니다.

Step 1. SQL 인젝션 — 입력창이 DB를 조종당하는 원리

SQL 인젝션은 지금도 웹 공격 중 가장 위험한 유형으로 꼽힙니다. OWASP Top 10에서 인젝션(Injection) 항목은 2013년과 2017년 판에서 1위를 차지했고, 2021년 최신판에서도 3위(A03)에 올라 있는 대표 위협입니다. 오래된 위협이라고 방심할 수 없는 이유가 여기 있습니다.

원리를 쉽게 설명하면 이렇습니다. 회원가입 폼이나 검색창, 로그인 창처럼 사용자가 텍스트를 입력하는 모든 곳은 그 값을 서버가 받아 데이터베이스(DB)에 질의(쿼리)를 보내는 데 사용합니다. 그런데 이 입력값을 제대로 걸러내지 않고 그대로 쿼리 문자열에 이어 붙이면, 공격자가 일반 텍스트가 아니라 DB 명령어로 해석될 수 있는 특수한 문자열을 입력했을 때 서버가 이를 진짜 명령으로 착각해 실행해버리는 문제가 발생합니다.

쉽게 비유하면, "이름을 알려주세요"라는 질문에 답변 대신 상대방에게 새로운 지시를 내리는 문장을 끼워 넣는 것과 비슷합니다. 질문을 받는 쪽이 답변과 지시를 구분하지 못하면, 엉뚱한 지시까지 그대로 수행해버리는 셈이죠. 이 문제로 인해 로그인 없이 관리자 권한을 얻거나, 회원 개인정보 전체가 유출되거나, 심하면 DB 자체가 삭제되는 피해까지 발생할 수 있습니다.

방어 방법은 명확하게 정립되어 있습니다.

첫째, 파라미터 바인딩(Prepared Statement)을 기본 적용하는 것입니다. 이는 사용자가 입력한 값을 DB 명령어의 일부가 아니라 "순수한 데이터"로만 취급하도록 미리 쿼리의 틀을 고정해두는 방식입니다. SQL 인젝션에 대한 표준 방어 기법으로 널리 인정받고 있으며, 대부분의 최신 개발 프레임워크에서 기본으로 지원합니다.

둘째, 화이트리스트 기반의 서버 측 입력 검증을 함께 적용해야 합니다. 예를 들어 전화번호 입력란이라면 숫자와 하이픈만 허용하고, 이메일 입력란이라면 이메일 형식에 맞는 문자만 통과시키는 방식입니다. 브라우저(클라이언트) 단에서만 검증하고 서버에서는 검증하지 않는 경우가 실무에서 자주 발견되는 허점이니 꼭 확인이 필요합니다.

셋째, DB 계정의 권한을 최소한으로 제한하는 것도 중요합니다. 웹 애플리케이션이 사용하는 DB 계정에 불필요하게 관리자 권한을 부여해두면, 설령 인젝션이 뚫리더라도 피해 범위가 DB 전체로 확산될 수 있습니다. 실제 서비스 운영에 필요한 최소한의 읽기·쓰기 권한만 부여하는 것이 원칙입니다.

> 🔎 자기 점검 질문: 우리 홈페이지의 모든 DB 조회 코드가 파라미터 바인딩 방식으로 작성되어 있는지, 담당 개발자에게 직접 확인해보셨나요?

Step 2. XSS(크로스사이트 스크립팅) — 남의 브라우저에서 실행되는 악성 스크립트

XSS는 공격자가 직접 서버를 공격하는 게 아니라 다른 방문자의 브라우저를 공격 도구로 이용한다는 점에서 SQL 인젝션과 다른 결이 있습니다. OWASP 2021년판에서는 XSS가 별도 항목이 아니라 인젝션(Injection) 카테고리에 통합 분류되어 있는데, 이는 XSS 역시 신뢰할 수 없는 데이터가 검증 없이 실행 가능한 형태로 흘러 들어간다는 점에서 본질이 같기 때문입니다.

작동 원리를 풀어보면, 게시판 댓글이나 게시글 작성란에 스크립트 코드가 포함된 텍스트를 입력했을 때, 이 사이트가 해당 텍스트를 그대로 화면에 출력해버리면 문제가 시작됩니다. 이후 다른 방문자가 그 게시글이나 댓글을 볼 때, 텍스트인 줄 알았던 내용이 그 방문자의 브라우저 안에서 실제로 실행되어 버립니다.

이렇게 실행된 스크립트는 방문자의 로그인 세션 정보를 몰래 탈취하거나, 화면을 조작해 가짜 로그인 창을 띄우거나, 사용자 모르게 다른 페이지로 이동시키는 등의 피해를 일으킬 수 있습니다. 특히 세션 탈취는 피해자가 로그인한 상태 그대로 공격자가 그 계정을 사용할 수 있게 된다는 점에서 매우 위험합니다.

방어책은 크게 세 가지 축으로 나뉩니다.

첫째, 출력 시 이스케이프(escape) 처리를 반드시 적용해야 합니다. 사용자가 입력한 텍스트를 화면에 보여줄 때, 스크립트로 해석될 수 있는 특수 문자들을 "이건 코드가 아니라 순수한 글자다"라고 명시적으로 표시해서 브라우저가 실행하지 않고 단순 텍스트로만 표시하도록 처리하는 것입니다.

둘째, CSP(Content Security Policy, 콘텐츠 보안 정책) 헤더를 적용하는 것입니다. CSP는 "이 페이지에서는 정해진 출처의 스크립트만 실행을 허용한다"는 규칙을 브라우저에 미리 알려주는 방식으로, 설령 악성 스크립트가 페이지에 삽입되더라도 실행 자체를 브라우저 단에서 차단할 수 있는 추가 방어선이 됩니다.

셋째, 입력 필터링입니다. 사용자가 입력할 수 있는 태그와 속성을 제한적으로 허용하는 방식으로, 게시판처럼 일부 HTML 태그(굵게, 링크 등)를 허용해야 하는 서비스라면 허용 목록에 없는 태그와 스크립트는 저장 단계에서부터 제거하는 필터링 로직이 필요합니다.

> 🔎 자기 점검 질문: 게시판·댓글·리뷰 기능이 있다면, 사용자가 입력한 내용이 화면에 출력될 때 이스케이프 처리가 적용되고 있는지 확인해보셨나요?

Step 3. 파일 업로드 취약점 — 이미지인 척 올라오는 웹셸 차단하기

파일 업로드 기능은 편리한 만큼 관리가 소홀하면 서버 전체를 내주는 가장 치명적인 통로가 될 수 있습니다. 프로필 사진, 첨부파일, 상품 이미지 업로드처럼 일상적인 기능이지만, 여기에 확장자 검증이 허술하면 공격자는 이미지 파일처럼 보이도록 위장한 실행 파일(웹셸)을 업로드해서 서버 안에 숨겨둘 수 있습니다.

웹셸이란 서버에서 실행 가능한 스크립트 형태로 만들어진 파일로, 한 번 업로드에 성공하면 공격자는 브라우저로 그 파일 경로에 접속하는 것만으로 서버 내부 명령을 원격으로 실행할 수 있게 됩니다. 이는 단순한 데이터 유출을 넘어서 서버 자체를 장악당하는 수준의 피해로 이어질 수 있는 매우 심각한 취약점입니다.

이를 막기 위한 체크리스트는 다음 네 가지로 정리할 수 있습니다.

첫째, 확장자 화이트리스트 방식을 적용해야 합니다. 업로드를 금지할 확장자를 나열하는 블랙리스트 방식이 아니라, 허용할 확장자(jpg, png, pdf 등)만 명시적으로 지정하고 그 외는 전부 차단하는 방식이 안전합니다. 블랙리스트는 변형된 확장자나 새로운 실행 확장자가 등장할 때마다 뚫릴 위험이 있습니다.

둘째, 파일 내용(매직바이트) 검증이 필요합니다. 파일 확장자는 사용자가 임의로 바꿀 수 있는 이름표에 불과하기 때문에, 확장자만 믿지 말고 파일 내부의 실제 데이터 구조(매직바이트, 헤더 정보)를 읽어서 진짜 이미지 파일이 맞는지 확인하는 절차가 함께 있어야 합니다.

셋째, 업로드 폴더의 실행 권한을 제거해야 합니다. 설령 악성 파일이 업로드에 성공하더라도, 그 폴더 자체가 스크립트를 실행할 수 없도록 서버 설정에서 실행 권한을 원천적으로 차단해두면 웹셸이 동작하지 못합니다. 이는 확장자 검증이 우회당했을 때를 대비한 2차 방어선으로 매우 중요합니다.

넷째, 파일 용량 제한입니다. 지나치게 큰 파일 업로드를 허용하면 서버 자원 고갈을 노린 공격에 취약해질 수 있으므로, 서비스 성격에 맞는 적절한 상한선을 설정해두는 것이 좋습니다.

> 🔎 자기 점검 질문: 업로드 폴더에 저장된 파일이 스크립트처럼 실행되는지, 실제로 테스트 환경에서 확인해본 적이 있으신가요?

Step 4. 비밀번호·로그인 보안 — 계정 탈취를 막는 기본기

비밀번호 저장 방식 하나만 제대로 갖춰도 계정 탈취 피해의 상당 부분을 예방할 수 있습니다. 많은 사람들이 오해하는 부분이 있는데, 안전한 비밀번호 저장이란 "암호화해서 저장하는 것"이 아니라 "복호화가 애초에 불가능한 단방향 해시(Hash) 방식으로 저장하는 것"을 의미합니다.

암호화는 열쇠만 있으면 원래 값으로 되돌릴 수 있는 방식이지만, 해시는 한 번 변환되면 원래 값으로 되돌릴 수 없는 일방통행 함수입니다. 만약 DB가 유출되더라도 비밀번호 원문이 복원될 수 없도록 하는 것이 핵심 목적이기 때문에, 반드시 해시 방식을 써야 합니다.

여기에 더해 솔트(Salt)를 반드시 함께 적용해야 합니다. 솔트란 각 비밀번호마다 추가하는 임의의 문자열로, 이것이 없으면 동일한 비밀번호를 쓰는 두 사용자의 해시값이 똑같아져서 공격자가 미리 계산해둔 해시 목록(레인보우 테이블)으로 원문을 역추적할 위험이 커집니다. 솔트를 적용하면 같은 비밀번호라도 사용자마다 전혀 다른 해시값이 만들어져 이런 공격을 무력화할 수 있습니다.

비밀번호 저장 방식 외에도 로그인 프로세스 전반에서 챙겨야 할 항목들이 있습니다.

로그인 시도 횟수 제한은 필수입니다. 같은 계정에 대해 짧은 시간 안에 반복적으로 로그인을 시도하는 패턴(무차별 대입 공격, 브루트포스)을 감지해 일정 횟수 실패 시 일시적으로 잠그거나 추가 인증을 요구하는 방식이 표준적으로 적용되어야 합니다.

세션 만료와 재발급 관리도 중요한 항목입니다. 로그인 후 발급되는 세션이 무제한으로 유지되면, 세션 정보가 유출됐을 때 피해가 장기화될 수 있습니다. 일정 시간이 지나면 자동 만료되도록 설정하고, 비밀번호 변경이나 중요한 개인정보 수정 시에는 기존 세션을 폐기하고 새 세션을 발급하는 방식이 안전합니다.

> 🔎 자기 점검 질문: 우리 서비스의 회원 비밀번호가 솔트를 포함한 단방향 해시로 저장되고 있는지, DB 구조를 아는 담당자에게 확인해보셨나요?

자주 발생하는 오류 — 외주 개발과 관리자 페이지에서 생기는 허점

보안 취약점의 상당수는 코드 자체보다 계약·검수 과정에서 놓친 부분에서 비롯됩니다. 특히 홈페이지를 외주로 제작했다면, 개발이 끝난 뒤 뒤늦게 보안 문제를 발견하는 경우가 적지 않습니다. 계약 단계부터 미리 챙겨야 할 항목들을 정리해보겠습니다.

첫째, 계약서에 KISA 소프트웨어 개발보안(시큐어코딩) 가이드 준수를 명시하는 것이 좋습니다. KISA(한국인터넷진흥원)는 국내 소프트웨어 개발보안 가이드를 공개적으로 제공하고 있으며, 특히 행정기관 정보시스템 개발에는 개발보안 적용이 제도적으로 의무화되어 있습니다. 민간 사이트라도 이 가이드를 검수 기준으로 삼으면 최소한의 보안 수준을 담보할 수 있습니다.

둘째, 관리자 페이지 접근 제한을 반드시 확인해야 합니다. 관리자 페이지 주소가 누구나 유추 가능한 형태로 노출되어 있거나, IP 제한 없이 외부에서 자유롭게 접근 가능한 상태라면 이는 공격의 최우선 표적이 됩니다.

셋째, 오픈 전 취약점 점검 결과를 문서로 확인하는 절차가 필요합니다. 개발이 끝났다는 것과 보안 점검이 끝났다는 것은 별개의 개념입니다. 오픈 전에 별도의 점검 리포트를 요청하고 결과를 검토하는 습관이 필요합니다.

아래는 실무에서 자주 발견되는 오류 유형과 해결 방향을 정리한 표입니다.

활용 팁 & 베스트 프랙티스 — 오픈 후에도 계속해야 할 습관

웹 보안은 오픈 시점 한 번의 점검으로 끝나는 것이 아니라 운영 기간 내내 이어가야 하는 습관입니다. 아무리 완벽하게 만들었더라도 시간이 지나면서 새로운 취약점이 발견되고, 사용하는 솔루션과 플러그인의 버전이 낡아가면서 위험도가 계속 높아지기 때문입니다.

가장 먼저 챙길 것은 솔루션·플러그인 보안 업데이트입니다. 게시판, 결제 모듈, CMS(콘텐츠 관리 시스템) 등 사용 중인 모든 구성 요소는 제작사에서 보안 패치를 배포할 때마다 최대한 빠르게 적용하는 것이 원칙입니다. 오래된 버전을 방치하는 것은 이미 알려진 취약점을 그대로 열어두는 것과 같습니다.

다음으로 정기 백업과 복원 테스트를 습관화해야 합니다. 백업 자체는 대부분 하고 있지만, 실제로 그 백업본으로 복원이 되는지 테스트해본 적이 있는지는 별개의 문제입니다. 백업 파일이 손상되어 있거나 복원 절차 자체에 오류가 있다면, 사고 발생 시 백업의 의미가 없어집니다. 최소 분기별로 한 번씩은 복원 테스트를 진행해보는 것을 권장합니다.

그리고 로그 확인입니다. 서버와 애플리케이션 로그에는 비정상적인 접근 시도, 반복된 로그인 실패, 알 수 없는 파일 업로드 시도 등의 흔적이 남습니다. 평소에 로그를 들여다보는 습관이 있으면 사고가 커지기 전에 이상 징후를 조기에 발견할 수 있습니다.

마지막으로 최근 들어 특히 중요해진 부분인데, AI가 생성한 코드라 하더라도 입력 검증 로직과 API 키 등 민감 정보의 하드코딩 여부는 반드시 사람이 재확인해야 합니다. AI 코드 생성 도구가 보편화되면서 개발 속도는 빨라졌지만, 생성된 코드가 보안 원칙을 항상 완벽하게 지키는 것은 아닙니다. 특히 입력값 검증 누락이나 키 값이 코드에 그대로 노출되는 문제는 AI가 생성한 코드에서도 반복적으로 발견될 수 있는 부분이니, 코드 리뷰 단계에서 사람이 한 번 더 점검하는 절차를 생략하지 않는 것이 좋습니다.

응용·확장 — 조직 전체의 보안 문화로 확장하기

개인의 점검을 넘어 조직 차원의 보안 프로세스로 확장하면 훨씬 안정적인 운영이 가능해집니다. 이 체크리스트를 한 번 점검하고 끝내는 것이 아니라, 정기적으로 반복되는 프로세스로 자리 잡게 만드는 것이 다음 단계입니다.

예를 들어 분기별 보안 점검 일정을 캘린더에 고정해두고, 이번 글에서 다룬 7가지 체크리스트 항목을 매번 동일한 양식으로 재확인하는 방식을 추천합니다. 새로운 기능이 추가될 때마다(특히 입력창이나 파일 업로드 기능이 새로 생길 때) 이 체크리스트를 다시 한번 적용해보는 것도 좋은 습관입니다.

또한 담당자가 바뀌거나 외주 개발사를 교체하는 시점에는 이전 담당자·개발사가 어떤 보안 조치를 적용했는지 인수인계 문서로 남겨두는 것이 중요합니다. 보안 설정은 눈에 보이지 않는 부분이 많기 때문에, 문서화가 되어 있지 않으면 담당자 교체 후 왜 이런 설정이 되어 있는지 아무도 모르는 상황이 벌어질 수 있습니다.

규모가 있는 조직이라면 모의 침투 테스트(외부 전문 인력이 실제 공격을 모사해 취약점을 찾는 절차)를 정기적으로 진행하는 것도 고려해볼 만합니다. 개발 단계의 점검만으로는 발견하기 어려운 실전 취약점이 발견되는 경우가 많기 때문입니다.

점검 체크리스트 — 오늘 바로 확인해볼 7가지

지금까지 다룬 내용을 실전에서 바로 활용할 수 있도록 7가지 항목으로 정리했습니다.

① SQL 쿼리에 파라미터 바인딩(Prepared Statement)이 전 구간 적용되어 있는가
② 모든 입력창에 서버 측 화이트리스트 검증이 걸려 있는가
③ 게시판·댓글 출력 시 이스케이프 처리와 CSP 헤더가 적용되어 있는가
④ 파일 업로드 시 확장자 화이트리스트와 매직바이트 검증이 함께 이뤄지는가
⑤ 업로드 폴더의 실행 권한이 제거되어 있는가
⑥ 비밀번호가 솔트 포함 단방향 해시로 저장되고 로그인 시도 제한이 걸려 있는가
⑦ 정기 백업 복원 테스트와 플러그인 업데이트가 습관화되어 있는가

이 7가지 중 하나라도 "모른다"는 답이 나온다면, 그 항목부터 담당자와 함께 확인해보시길 권합니다.

자주 묻는 질문 FAQ

Q1. 작은 규모의 홈페이지도 정말 공격 대상이 되나요?
네, 공격의 상당수가 특정 대상을 노린 것이 아니라 자동화 봇이 무작위로 취약점을 스캔하는 방식으로 이뤄지기 때문에 규모나 인지도와 무관하게 표적이 될 수 있습니다.

Q2. XSS와 SQL 인젝션은 같은 공격인가요?
근본 원리(신뢰할 수 없는 데이터가 검증 없이 처리됨)는 유사하지만, SQL 인젝션은 DB를 대상으로 하고 XSS는 다른 방문자의 브라우저를 대상으로 한다는 점에서 다릅니다. OWASP 2021년판에서는 두 위협이 큰 틀에서 인젝션 카테고리로 함께 분류되어 있습니다.

Q3. 이 체크리스트를 우리가 직접 다 확인할 수 있나요?
개발 지식이 없어도 이 글에 정리된 질문들을 그대로 담당 개발자나 외주사에 전달해 답변을 받는 방식으로 충분히 점검 가능합니다.

Q4. 보안 점검은 얼마나 자주 해야 하나요?
최소 분기별 점검을 권장하며, 새로운 기능(특히 입력창·파일 업로드 관련)이 추가될 때마다 재점검하는 것이 좋습니다.

Q5. 오래된 홈페이지도 지금 점검이 의미가 있나요?
오히려 오래된 사이트일수록 검증 로직이 낡아있거나 플러그인이 오래됐을 가능성이 높아 점검의 필요성이 더 큽니다.

---

웹 보안은 한 번의 완벽한 구축으로 끝나는 것이 아니라, 꾸준한 점검과 습관으로 유지되는 영역입니다. 오늘 정리한 7가지 체크리스트를 출력해두고, 담당 개발자 혹은 외주사와 하나씩 짚어보는 시간을 가져보시길 권합니다. 참고 자료로는 KISA 소프트웨어 개발보안 가이드와 OWASP 공식 사이트(owasp.org)를 함께 살펴보시면 더 깊이 있는 이해에 도움이 될 것입니다.