웹사이트에서 보안 위험을 제거하는 방법

웹사이트 보안의 7대 위험을 제거하는 방법

개선 전

제3자 전문 보안 테스트 업체에서 테스트를 진행하고, 주요 이슈 목록

문제 1: SQL 주입 공격에 취약

위험: 공격자가 애플리케이션을 통해 데이터베이스 명령을 보낼 수 있으며 이러한 명령은 서버에 의해 실행됩니다. 이는 데이터베이스를 완벽하게 제어하는 ​​데 사용될 수 있습니다. 이러한 SQL 주입 취약점은 필드 중 하나에 "and?7?=?7?-" 또는 "and?8?=?9?-"를 삽입하고 결과를 비교하여 확인할 수 있습니다.

분석: SQL 주입 공격은 서버의 매개변수 확인이 충분하지 않아 공격자가 민감한 정보를 탈취할 수 있기 때문에 발생합니다. 따라서 공격자가 데이터베이스의 SQL 쿼리 문을 조작할 수 없도록 매개변수화된 쿼리를 사용해야 합니다. 예를 들어, 애플리케이션에 이름이 필요한 경우 알파벳 문자, 공백, 아포스트로피만 허용해야 하며 다른 문자는 허용하지 않습니다. 즉, 애플리케이션의 모든 입력 필드에 서버측 화이트리스트 기술을 구현하십시오. 특히 공백이 필요한 SQL 문에 사용되는 모든 입력 필드는 따옴표로 묶어야 합니다.

개선: 위험한 문자를 필터링하기 위해 외부 매개변수를 허용하는 프로그램의 모든 위치를 하나씩 식별합니다. 예를 들어, 전역 함수에 "금지된 문자열 목록"을 정의하는 경우 이 표에는 필터링할 SQL 공격 코드에 포함될 수 있는 문자열이 나열됩니다.

and?|exec?|insert?|select?|delete?|update?|count?|?*?|chr?|mid?|master?|truncate?|char?|declare?| lt;|gt;|'|(|)|{|}

//물론 이 목록은 웹사이트의 특성에 따라 개선 및 수정될 수 있습니다

그럼 다음:

p>

문제 2: 크로스 사이트 스크립팅에 취약함

위험: 이 취약성을 악용하여 인증 쿠키를 얻거나 관리자 계정을 공격하거나 사용자를 허용할 수 있습니다. 다른 서버 및 시스템을 공격하는 응용 프로그램입니다. 해당 취약점은 특정 영역에 "lt;scriptgt;alert('23389950');lt;/scriptgt;"를 삽입하여 확인할 수 있습니다.

분석: 또한 이 웹사이트의 모든 입력 필드에 서버측 화이트리스트 기술을 구현해야 합니다. 특수 문자가 필요한 경우 보다 안전한 형식으로 변환해야 합니다. 예를 들어 다양한 언어에 적용 가능한 HTML 트랜스코딩:

amp; ?amp;로 변환해야 함

"로 변환해야 함";

' amp;39;

gt;로 변환해야 합니다;;

lt;로 변환해야 합니다.

개선 사항: 이러한 표준 HTML 트랜스코딩 외에도 의심스러운 문자열에 대한 향상된 검사 및 변환도 필요하며 다음 작업이 추가로 수행됩니다. (1) 각 페이지의 입력 매개변수 검사 강화( 2) 기존에는 클라이언트 측에서만 판단했던 매개변수에 대해 서버 측 검사를 더욱 강화했습니다. (3) 마지막으로 글로벌 트랜스코딩 및 필터링 기능을 제공합니다. 물론 이를 위해서는 성능, 확장성, 보안을 균형있게 고려해야 합니다.

문제 3: 안전하지 않은 CrossDomain.XML 파일

위험: Flash/Flex 시스템의 크로스 도메인 문제를 해결하기 위해 crossdomain.xml 크로스 도메인 정책 파일 제안됩니다. 크로스 도메인 문제를 해결할 수는 있지만 악의적인 공격의 위험도 있습니다. 정책 파일이 모든 도메인에 대한 액세스를 허용하는 경우 네트워크 서버에 대한 크로스 사이트 요청 위조 및 크로스 사이트 스크립팅 공격이 허용될 수 있습니다. 예를 들어, 안전하지 않은 Flash 응용 프로그램은 로컬 데이터 및 사용자가 저장한 웹 페이지 기록에 액세스할 수 있으며 심지어 바이러스 및 악성 코드를 퍼뜨릴 수도 있습니다.

분석: 보안 리소스를 제공하는 신뢰할 수 있는 도메인만 허용하는지 확인하는 방법을 고려하세요.

개선 사항: 조사 결과 프로그램 디렉토리에 있는 crossdomain.xml 파일의 구성이 다음과 같은 것으로 확인되었습니다.

lt;?xml?version=”1.0″? gt;

lt;!DOCTYPE?cross-domain-policy?SYSTEM?”/xml/dtds/cross-domain-policy.dtd”gt;

lt;교차 도메인 -policygt;

lt;allow-access-from?domain="*"?/gt;

lt;/cross-domain-policygt;

allow- 파일에서 access-from? 엔터티는 별표로 설정되어 있으며 모든 도메인에서의 액세스를 허용하도록 설정되어 있습니다. ?lt;allow-access-from?domain="*.example.com"?/ gt;는 이 도메인에만 접근이 허용된다는 의미입니다.

질문 4: Flash 매개변수 AllowScript-Access?가 항상으로 설정되었습니다.

위험: AllowScriptAccess가 항상인 경우 이는 삽입된 타사 플래시 파일이 코드를 실행할 수 있음을 나타냅니다. 이제 공격자는 이 결함을 이용해 타사 플래시 파일을 삽입하고 악성 코드를 실행할 수 있습니다.

분석: AllowScriptAccess 매개변수는 "always", "sameDomain" 또는 "never"일 수 있습니다. 세 가지 선택적 값 중 "항상"은 Flash 파일이 HTML 페이지와 다른 도메인에서 가져온 경우에도 Flash 파일이 해당 파일이 포함된 HTML 페이지와 통신할 수 있음을 의미합니다. 매개 변수가 "sameDomain"인 경우 플래시 파일은 해당 파일이 포함된 HTML 페이지와 동일한 도메인에서 가져온 경우에만 HTML 페이지와 통신할 수 있습니다. 이 값은 AllowScriptAccess?의 기본값입니다. AllowScriptAccess가 "never"이면 Flash 파일은 HTML 페이지와 통신할 수 없습니다.

따라서 한 도메인의 Flash 파일이 다른 도메인의 HTML 페이지에 있는 스크립트에 액세스하지 못하도록 하려면 AllowScriptAccess 매개변수를 "sameDomain"으로 설정해야 합니다.

개선

lt;param

name="allowScriptAccess"?value="always"?/gt;

다음으로 변경됨

lt;param

name="allowScriptAccess"?value="sameDomain"?/gt;

문제 5: 웹사이트 백엔드 관리가 안전하지 않은 링크를 통해 구현됩니다

위험: 관리 액세스는 SSL을 적용하지 않으므로 공격자가 계정 자격 증명을 포함하여 사용자와 서버 간에 전송되는 모든 데이터를 모니터링하고 수정할 수 있습니다. 공격자가 프록시나 라우팅 소프트웨어를 통해 서버와 관리자 사이의 통신을 가로채는 경우 민감한 데이터가 가로채어지고 관리자의 계정이 도용될 수 있습니다.

분석: 관리 액세스에는 SSL이 적용되지 않습니다. 데이터 가로채기를 방지하려면 관리 액세스에 HTTPS(SSL3.0)를 적용해야 합니다.

개선: 운영 및 유지 관리를 통해 서버에 대한 구성이 조정되었으며, 별도의 구성이 관리 백엔드에 대한 SSL3.0 액세스를 지원합니다.

문제 6: 인증 링크를 우회할 수 있음

위험: 사용자가 정보를 게시할 때 자동 악성 게시를 방지하기 위해 페이지에 인증 코드가 있음에도 불구하고 여전히 우회될 수 있습니다. 자동 제출용.

우회하는 방법 중 하나는 필터링 및 식별 소프트웨어를 사용하는 것이고, 다른 하나는 쿠키나 세션 정보를 이용하여 인증코드를 우회하는 것입니다.

분석: 이미지 왜곡 메커니즘 자체는 그다지 강력하지 않으며 공개적으로 사용 가능한 필터링 및 인식 소프트웨어를 사용하면 쉽게 식별할 수 있습니다. 생성된 이미지도 예측 가능합니다. 사용된 문자 집합이 단순하므로(단순 숫자) 보다 강력한 보안 문자 시스템을 구현하는 것이 좋습니다.

쿠키 또는 세션 정보 처리에는 인증 코드를 우회하는 허점이 있습니다. 각 링크가 고유한 인증 코드만 얻을 수 있는지 확인하고 각 요청이 새로운 인증 코드를 생성하고 요구하는지 확인하세요.

개선: 한 자리 숫자가 아닌 필요에 따라 인증 코드의 복잡성을 높입니다.

분석 결과 Session에 인증코드가 저장되어 있는 것으로 확인되었으며, 개발자가 제출 후 Session에서 인증코드 값을 지우는 것을 잊어버려서 인증코드가 Session 내에서 사용 가능한 것으로 확인되었습니다. 만료 시간은 여러 커밋을 활용할 수 있습니다. 따라서 제출 후 시간 내에 인증 코드를 삭제하는 작업이 추가됩니다.

문제 7: 민감한 정보 공개

위험: 이 정보는 다른 취약점을 악용하는 데만 사용할 수 있으며 애플리케이션을 손상시키는 데 직접 사용할 수 없습니다. 민감한 디렉터리에 대한 정보는 웹 사이트의 robots.txt 파일에서 얻을 수 있으며, 이를 통해 공격자는 응용 프로그램 내부에 대한 추가 정보를 얻을 수 있으며, 이는 다른 취약점을 악용하는 데 사용될 수 있습니다.

분석: robots.txt는 관리 인터페이스 정보를 제공해서는 안 됩니다. robots.txt 파일이 웹사이트 구조를 노출하는 경우 검색 엔진 로봇이 이 콘텐츠를 크롤링하지 못하도록 민감한 콘텐츠를 격리된 위치로 이동해야 합니다.

개선: 물론 robots.txt는 SEO 요구 사항에 따라 처리되어야 하지만 보안에도 주의를 기울여야 합니다. 예: disallow:/testadmin/, 여기서 testadmin은 관리 배경이며 노출됩니다. 실제 상황에 따라 robots.txt 파일을 삭제해야 할지, 검색 엔진 검색을 금지하도록 민감한 디렉터리를 별도로 구성해야 할지 결정할 수 있습니다.

다른 문제 요약

이 외에도 상대적으로 덜 해로운 다른 문제도 많이 있으며 아래에서 분석됩니다.

문제: 계정 존재 여부에 따라 오류 메시지가 다르기 때문에 로그인 페이지를 통해 사용자 이름을 열거하는 것이 가능합니다.

대책: "입력한 이메일 주소나 비밀번호가 틀렸습니다!" 등의 오류 메시지가 나오지 않고, 일정 횟수 초과 시 IP가 잠기도록 수정합니다.

문제: 테스트 파일, bak 파일, 임시 파일 등 민감한 정보를 유출하거나 악의적으로 사용될 수 있는 중복 파일이 감지되었습니다.

대책: 해당 파일을 서버에서 제거하세요.

문제: 사용자 주문과 쉽게 연관될 수 있는 order라는 파일과 같은 잠재적인 기밀 정보가 발견되었습니다.

대책: 파일 이름에 민감한 단어 전체를 포함하지 않거나, 추측하기 쉬운 파일에 민감한 정보를 저장하지 않거나, 해당 정보에 대한 액세스를 제한하지 마세요.

문제: 내부 정보 유출이 발견되었습니다.

대책: 코드에서 누락된 내부 IP 주소, 내부 조직, 인사 관련 정보 등을 제거하세요.

*** 원인 분석

발견된 문제 중 71개는 애플리케이션과 관련된 보안 문제였습니다. 애플리케이션 관련 보안 문제는 애플리케이션 코드의 결함으로 인해 수정될 수 있습니다. 29는 인프라 및 플랫폼 보안 문제로, 이러한 보안 문제는 타사 제품의 잘못된 구성이나 결함으로 인해 발생하므로 시스템 또는 네트워크 관리자가 수정할 수 있습니다.

주된 이유는 다음 세 가지 측면을 포함하지만 이에 국한되지는 않습니다.

절차적 측면

사용자 입력 시 위험한 문자가 올바르게 정리되지 않습니다.

쿠키 및 세션을 사용할 때 보안 고려 사항이 충분하지 않습니다.

HTML 주석이나 숨겨진 양식에는 민감한 정보가 포함되어 있습니다.

사용자에게 제공된 오류 정보에는 민감한 정보가 포함되어 있습니다.

웹 페이지에 있는 프로그래머의 디버깅 정보는 제때 삭제되지 않습니다.

웹 애플리케이션 프로그래밍이나 구성은 안전하지 않습니다.

구성 측면

웹 디렉토리에 남아 있는 중복 파일은 제때 정리되지 않습니다.

웹 서버 또는 애플리케이션 서버가 안전하지 않은 방식으로 구성되었습니다.

보안 사양 문서가 완전하지 않고 개발자 교육도 부족하다.

개발자의 보안 관련 경험과 보안 인식이 부족하다.

이러한 문제에 대한 해결책 - 기술을 넘어서

보안 문제 자체에 대한 해결책은 사례별일 수 있지만, 더 많은 잠재적인 문제를 방지하기 위해 도입, 개선 기술 이외의 측면도 무시할 수 없습니다.

1. 보안 인식을 강화하기 위해 프로젝트 초기 단계에서 개발자를 대상으로 보안 개발 교육을 실시합니다.

2. 안전 경험 공유 플랫폼을 구축하고, 경험 체크리스트를 안전 가이드 문서로 구성합니다.

3. 향후 사용을 위해 성숙한 코드 결과를 공개 보안 모듈로 추출합니다.

이번 개선 이후에 일반적으로 사용되는 몇 가지 기본 보안 원칙을 참고할 수 있도록 요약했습니다. "비공식적이고 불완전한 웹사이트 개발에 대한 보안 원칙"을 참조하세요.

저자 소개: 현재 인터넷 회사에서 프로젝트 관리를 담당하고 있는 차오샤오쥐안(Chao Xiaojuan). InfoQ 중국 웹사이트 SOA 커뮤니티 편집자는 프로젝트 관리, 아키텍처 및 제품에 중점을 두고 웹 개발 관리 분야에서 다년간의 경험을 보유하고 있습니다.

(이 기사는 "Programmer" 잡지, 2013년 2호에서 발췌)