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

웹 사이트 보안의 7 가지 주요 위험을 제거하는 방법

개선 전

타사 전문 보안 테스트 회사에서 테스트를 실시한 주요 문제 목록은 다음과 같습니다.

질문 1: SQL 주입 공격에 취약함

위험: 공격자는 응용 프로그램을 통해 데이터베이스 명령을 전송할 수 있으며, 이러한 명령은 서버에서 실행됩니다. 데이터베이스를 완전히 제어하는 데 사용할 수 있습니다. 이러한 SQL 주입 취약점은 영역 중 하나에 "and" 를 삽입하여 삽입할 수 있습니까? 7? =? 7? -'또는' and'? 8? =? 9? -"를 입력하고 결과를 비교하여 판단합니다.

분석: SQL 주입 공격은 서버가 매개변수 검사에 부족하기 때문에 공격자가 민감한 정보를 얻을 수 있습니다. 따라서 공격자가 데이터베이스의 SQL 쿼리 문을 조작할 수 없도록 파라메트릭 쿼리를 사용해야 합니다. 예를 들어, 응용 프로그램에 이름 입력이 필요한 경우 알파벳 문자, 공백 및 아포스트로피만 허용되어야 하며 다른 문자는 허용되지 않습니다. 즉, 응용 프로그램의 모든 입력 도메인에 서버측 화이트리스트 기술을 구현합니다. 특히 SQL 문에 사용되는 모든 입력 필드는 공백이 필요한 모든 입력 필드를 따옴표로 묶어야 합니다.

개선 사항: 프로그램에서 외부 매개변수를 허용할 수 있는 모든 장소를 하나씩 식별하여 위험 문자를 필터링합니다. 전역 함수에' 금지 문자열 목록' 이 정의된 경우 이 테이블에는 필터링할 SQL 공격 코드에 포함될 수 있는 문자열이 나열됩니다.

And? |exec? |insert? |select? |delete? | 업데이트? |count? |? *? |chr? |mid? | 마스터? |truncate? | 차? |declare? | lt; | gt; |'|(|)|{|}

//물론 사이트의 특성에 따라 이 목록을 개선하고 수정할 수 있습니다

다음 단계는 다음과 같습니다.

질문 2: 사이트 간 스크립팅 공격에 취약함

위험: 이 취약점은 인증 쿠키를 얻거나, 관리자 계정을 공격하거나, 응용 프로그램 사용자가 다른 서버 및 시스템을 공격하도록 하는 데 사용할 수 있습니다. 취약점은 영역에 "lt" 를 삽입하여 삽입 할 수 있습니다. 스크립트 gt; 알레트 ('23389950'); Lt; /scriptgt; " 판단할 수 있습니다.

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

Amp；; 다음으로 변환해야 합니까? Amp；; 을 눌러 섹션을 인쇄할 수도 있습니다

"다음으로 변환";

Amp； 로 변환되어야 합니다. 39;

Gt; Gt 로 변환되어야 합니다. 을 눌러 섹션을 인쇄할 수도 있습니다

Lt; Lt 로 변환되어야 합니다. 。

개선 사항: 이러한 표준 HTML 트랜스코딩 외에도 의심스러운 문자열에 대해 강화 검사 및 변환을 수행하고 (1) 각 페이지의 입력 매개 변수에 대해 강화 검사를 수행합니다. (2) 원래 클라이언트에서만 판단했던 매개변수에 대해 서버측에서 검사를 더욱 강화합니다. (3) 결국 글로벌 트랜스코딩 및 필터링 기능을 제공합니다. 물론 성능과 확장성, 보안 측면에서 균형 잡힌 고려가 필요합니다.

질문 3: 비보안 CrossDomain.XML 파일

위험: Flash/Flex 시스템의 도메인 간 문제를 해결하기 위해 crossdomain.xml 도메인 간 정책 파일이 제시되었습니다. 도메인 간 문제는 해결할 수 있지만 악성 공격의 위험도 있습니다. 정책 파일에서 모든 도메인에 대한 액세스가 허용되는 경우 네트워크 서버에 대한 사이트 간 요청 위조 및 사이트 간 스크립트 공격을 시작할 수 있습니다.

예를 들어, 안전하지 않은 플래시 응용 프로그램은 로컬 데이터와 사용자가 저장한 웹 페이지 레코드에 액세스할 수 있으며 바이러스와 악성 코드도 전파할 수 있습니다.

분석: 보안 리소스를 제공하는 신뢰할 수 있는 도메인에만 개방이 허용되는지 확인하는 방법을 고려합니다.

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

Lt; -응? Xml? Version=”1.0″ "? Gt;

Lt; ! DOCTYPE? Cross-domain-policy? 시스템? /XML/dtds/cross-domain-policy.dtd "gt;

Lt; Cross-domain-policy gt;

Lt; Allow-access-from? 도메인 = "*"? /gt;

Lt; /cross-domain-policygt;

파일의 allow-access-from? 엔티티가 별표로 설정되어 모든 도메인 액세스를 허용하도록 설정되어 있습니다.? Lt; Allow-access-from? 도메인 = "* .example.com"? /gt; , 도메인 액세스만 허용하면 문제가 해결됨을 나타냅니다.

질문 4: 플래시 매개 변수 AllowScript-Access? Always

로 설정되었습니다

위험: AllowScriptAccess 가 always 인 경우 포함된 타사 Flash 파일에서 코드를 실행할 수 있음을 나타냅니다. 이제 공격자는 이 결함을 타사 플래시 파일에 포함시켜 악의적인

를 수행할 수 있습니다

코드.

분석: AllowScriptAccess 매개변수는 "always", "sameDomain" 또는 "never" 일 수 있습니다. 세 가지 선택적 값 중 "always"? Flash 파일을 포함할 수 있음을 나타냅니까? HTML? Flash 파일이 HTML 페이지와 다른 도메인에서 온 경우에도 페이지가 통신합니다. 매개 변수가 [sameDomain] 인 경우 Flash 파일은 포함된 HTML 페이지와 동일한 도메인에 있는 경우에만 HTML 페이지와 통신할 수 있습니다. 이 값은 AllowScriptAccess? 에 설명된 시나리오에 따라 개념적 설계에 있는 매스의 볼륨을 해석합니다. 그리고 AllowScriptAccess 가? [never] 를 선택하면 Flash 파일이 어떤 HTML 페이지와도 통신할 수 없습니다.

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

개선

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 의 인증 코드 값을 비우는 것을 잊어 버렸기 때문에 인증 코드는 만료 시간 동안 계속 사용할 수 있어 여러 번 제출될 수 있습니다. 이에 따라 제출 후 확인 코드를 제때에 비우는 작업이 추가됐다.

질문 7: 민감한 정보 공개

위험: 이 정보는 다른 취약점을 활용하는 데만 사용할 수 있으며 응용 프로그램을 파괴하는 데는 직접 사용할 수 없습니다. 웹 사이트의 robots.txt 파일에서 민감한 디렉토리에 대한 정보를 얻을 수 있으므로 공격자가 응용 프로그램 내부에 대한 추가 정보를 얻을 수 있으며, 이 정보는 다른 취약점을 공격하는 데 사용될 수 있습니다.

분석: robots.txt 는 관리 인터페이스에 대한 정보를 제공해서는 안 됩니다. Robots.txt 파일에 웹 사이트 구조가 노출되면 검색 엔진 로봇이 컨텐츠를 검색하지 않도록 민감한 컨텐츠를 격리 위치로 이동해야 합니다.

개선 사항: 물론 robots.txt 는 SEO 의 요청에 따라 처리해야 하지만 보안에도 똑같이 주의해야 합니다. 예를 들면 disallow:/testadmin/입니다. 여기서 testadmin 은 관리 백그라운드입니다. 실제 상황에 따라 robots.txt 파일을 삭제하거나 민감한 디렉토리를 별도로 구성하여 검색 엔진 검색을 금지할 수 있습니다.

기타 문제 요약

이 밖에도 비교적 위험성이 낮은 다른 문제들이 많이 있는데, 아래와 같이 분석되었다.

문제: 계정에 오류 메시지가 있는지 여부에 따라 다르기 때문에 로그인 페이지를 통해 사용자 이름을 열거할 수 있습니다.

대책: "입력하신 사서함이나 비밀번호가 올바르지 않습니다!" 와 같은 힌트가 없도록 오류 메시지를 수정합니다. -응? 그리고 일정 횟수 이상 IP 를 잠급니다.

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

대책: 서버에서 해당 파일을 제거합니다.

문제: order 라는 파일과 같은 잠재적 기밀 정보를 발견하면 사용자 주문을 쉽게 연상할 수 있습니다.

대책: 파일 이름에 민감한 단어를 모두 포함하거나 쉽게 추측할 수 있는 파일에 민감한 정보를 보관하거나 액세스를 제한하지 마십시오.

문제: 내부 정보 유출 발견.

대책: 코드에서 누락된 내부 IP 주소, 내부 조직, 개인 관련 정보 등을 제거합니다.

* * * 성적 원인 분석

발견된 문제 중 71 은 어플리케이션과 관련된 보안 문제입니다. 응용 프로그램 코드의 결함으로 인해 응용 프로그램 관련 보안 문제를 수정할 수 있습니다. 29 는 인프라 및 플랫폼 보안 문제이며 시스템 또는 네트워크 관리자가' 인프라 및 플랫폼 보안 문제' 를 개정할 수 있습니다. 이러한 보안 문제는 타사 제품의 잘못된 구성이나 결함으로 인해 발생합니다.

종합의 주요 원인은 다음 세 가지 측면을 포함하지만 이에 국한되지는 않는다.

절차 측면

사용자 입력에 대한 위험 문자 정리가 제대로 수행되지 않았습니다.

쿠키와 세션 사용 시 보안 고려 사항 부족

HTML 주석 또는 Hidden? Form 에는 민감한 정보가 들어 있습니다.

사용자에게 제공되는 오류 메시지에는 중요한 정보가 포함되어 있습니다.

프로그래머는? 웹? 페이지의 디버그 정보 등은 제때에 삭제되지 않았다.

웹? 응용 프로그램 프로그래밍 또는 구성이 안전하지 않습니다.

구성 측면

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

웹 서버 또는 응용 프로그램 서버는 안전하지 않은 방식으로 구성됩니다.

안전 사양 문서가 완벽하지 않고 개발자의 교육이 부족합니다.

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

이러한 문제에 대한 해결책-기술 외

보안 문제 자체에 대한 해결책은 case 일 수 있습니까? 비? 케이스? 그러나 더 많은 잠재적 문제의 도입을 막기 위해 기술 이외의 개선도 간과해서는 안 된다.

1.? 개발자가 프로젝트 초기부터 안전개발을 하는 교육에 대해 안전의식을 강화하다.

2.? Checklist 를 보안 가이드로 사용하여 * * * 보안 경험을 즐길 수 있는 플랫폼을 구축합니다.

3.? 성숙한 코드 결과를 공개 * * * 보안 모듈로 추출하여 나중에 사용할 수 있도록 합니다.

이번 개선 이후 몇 가지 일반적인 기본 보안 원칙을 요약해 참고할 수 있도록' 비공식 불완전 사이트 개발 안전 원칙' 을 참조하십시오.

저자 소개: 효연이는 현재 인터넷 회사에서 프로젝트 관리를 담당하고 있습니다. InfoQ 중문역 SOA 커뮤니티 편집자는 다년간의 웹 개발 관리 경험을 가지고 있으며 프로젝트 관리, 아키텍처 및 제품에 초점을 맞추고 있습니다.

(이 기사는 프로그래머 잡지 13 년 02 호)