it-swarm-korea.com

Fortify 360-싱크 및 소스-취약점 수

애플리케이션 보안 환경에서 저는 매일 Fortify Software의 Fortify360을 사용합니다.

내 가장 큰 장애물 중 하나는 숫자 (소스 대 싱크)를 설명하는 것입니다.

Fortify는 검증되지 않은 데이터가 사용자에게 크로스 사이트 스크립팅 취약점으로 표시되는 소스 코드의 각 위치에 플래그를 지정합니다.

검증되지 않은 데이터가 사용자에게 표시되는 300 개의 위치 (싱크)가 있다고 가정 해 보겠습니다. 300 개의 싱크 중 데이터는 하나의 기능을 사용하여 데이터베이스에서 모두 가져옵니다. (출처)

Fortify는 이후 300 개의 교차 사이트 스크립팅 취약점이 있다고보고합니다. 명시 적으로 알려주지 않는 것은 그 중 300 개가 잠재적으로 동일한 위치에서 고정 될 수 있다는 것입니다.

응용 프로그램 보안 엔지니어의 관점에서 제 질문에 대해 고객에게 300 개의 교차 사이트 스크립팅 취약점 또는 1 개의 교차 사이트 스크립팅 취약점이 있다고보고합니까? 이 진술 중 하나가 정확합니까?

출처 또는 싱크를보고합니까?

현재 제가하고있는 일은 하나의 기능/방법 내에서 모두 수정 될 수있는 300 개의 잠재적 인 교차 사이트 스크립팅 취약점이 있다고보고하는 것입니다.

300 개 위치에 노출 된 크로스 사이트 스크립팅 취약점이 1 개 있다고 말하는 것이 더 정확합니까?

이 중 일부는 주관적이라는 것을 알고 있지만, 자신의 방법에 대해 밝힐 수있는 다른 분야의 의견을 찾고 있습니다.

8
Purge

나는 거의 항상 이것을 300 곳에 나타나는 하나의 취약점으로 언급 할 것입니다. 특히 이것이 50, 100 또는 그 이상의 취약점이있을 수있는 더 넓은 보고서의 일부인 경우, 그렇지 않으면 책처럼 두꺼운 보고서로 끝납니다. 조치를 취할 수 있습니다.

청중 측면에서 생각해보십시오. 그들은 위험에 대한 노출과 이에 대해 무엇을 할 수 있는지 알고 싶어 할 것입니다. 그들의 행동은 개인이나 팀을 지정하여 수정하는 것이므로 수정해야 할 문제가 한 가지 있다는 말을 듣고 싶어합니다. 문제가 발생하는 300 개의 인스턴스는 취약성보다 우선 순위가 더 높을 수 있습니다. 하나의 가시적 인스턴스이지만 수정은 동일 할 수 있습니다.

3
Rory Alsop

AviD의 답변을 반복합니다. Cross Site Scripting은 일반적으로 입력 유효성 검사 문제가 아닌 상황에 맞는 출력 인코딩 문제로 더 잘 해결됩니다. 입력 유효성 검사 문제로 해결하려는 경우 대부분의 경우 블랙리스트 입력 유효성 검사 접근 방식을 장려하거나 화이트리스트 접근 방식을 사용하는 경우 다음과 같이 가져 오지 못할 수 있습니다. 원하는대로 꽉 조입니다.

또한-각 출력 인코딩 컨텍스트 (HTML, 속성, CSS, JavaScript)에 대해 처리해야하는 사항이 다르므로 개발 팀을 Microsoft의 WPL (Web)과 같이 인코딩을 수행하는 작업으로 안내하는 것이 좋습니다. 보호 라이브러리) 또는 OWASP ESAPI 또는 OWASP Reform (다른 언어).

7
Justin Clarke

개인적으로 선호하는 바는 공급 업체 인 IBM에서 일하지만 제 생각에는 최선의보고 방법이 소스와 싱크를 제공하는 것입니다.

다른 출력 컨트롤 (싱크)이 전달 된 데이터를 다르게 인코딩하고 다른 입력 컨트롤 (소스)이 항상 URL 인코딩 형식에서 데이터를 인코딩 해제하지 않는 .NET 프레임 워크의 경우 특히 그렇습니다.

Java 사용하면 일반적으로 그다지 가변성이 보이지는 않지만 최적의 수정을 결정하기 전에 소스와 싱크를 모두 고려해야한다고 생각합니다.

4
Aaron

제 생각에는 XSS가 어디에 있는지, 그리고 어떻게 활용할 수 있는지는 중요하고 중요하지 않습니다.

XSS는 어느 정도 위험하기 때문에 중요하지 않습니다.

무해한 URI 및 매개 변수 구조의 XSS가 더 많은 피싱으로 이어지기 때문에 중요합니다. 여러면에서 (공격자의 관점에서) 애플리케이션 또는 인프라의 인증 된 방문자와 인증되지 않은 방문자/사용자 모두가 사용할 수있는 페이지에서 XSS를 사용할 수있는 것이 좋습니다.

이것을 XSS 대신 SQLi와 다르게 표현하면 상황이 훨씬 더 관련성이 높고 이해하기 쉬워집니다. SQLi의 각 인스턴스는 악용 가능성의 행사로 바뀔 수 있습니다. 블라인드 SQLi는 종종 악용하기가 더 어렵지만 중요하지 않습니다. 실제 핵심은 각 개별 SQLi 결함에 의해 노출 된 데이터 또는 무단 액세스입니다. CVSS와 DREAD가 떠오르지 만 실제로 이것은 CWSS 및 STRIDE처럼 더욱 최적화되어야합니다.

따라서-귀하의 질문에 답하기 위해-결정은 appsec 위험 관리의 연습이어야합니다. 취약성 범주 당 개별 결과가 1 개 이상 300 개 미만일 가능성이 높습니다. 나는 그것들을 소프트웨어의 약점으로 말하는 것을 선호하지만 이것은 당신의 타겟 청중에 따라 다를 수 있습니다. 특히 보고서 작성 작업에서 정보를 제공 할 때 대상 고객에 대한 사용자 정의가 항상 중요합니다.

다시 말하지만 소스 또는 싱크 (또는 둘 다)를 나열할지 여부는 대상 고객에 따라 다릅니다. 보고서를 받았다면 둘 다보고 싶었지만 응용 프로그램의 심층적 인 기술 평가자이기 때문입니다. 싱크는 대부분의 개발자에게 가장 유용하며 근본 원인 문제 (예 : 인코딩 (XSS 및 SQLi의 경우))에 초점을 맞출 수 있지만 다른 수정 및 심층 방어가있을 수 있습니다. 개발자뿐만 아니라 DBA, 시스템 관리자, 관리자 및 애플리케이션 및 시스템 라이프 사이클에 관련된 다른 사람을 위해 제시 할 전략.

그래서 제 대답은이 대답은 아마도 수천 또는 수백만의 다른 요인에 크게 의존한다는 것입니다.

2
atdre

답은 상황에 따라 다릅니다.

한 가지 설계 원칙은 데이터베이스의 모든 데이터를 신뢰할 수없고 삭제 된 것으로 간주하는 것이므로 HTML 출력에 포함하기 전에 HTML을 올바르게 인코딩하거나 이스케이프하는 것은 HTML을 출력하는 코드의 책임입니다. 그것이 당신의 프로젝트가 취한 접근 방식이라면, 이것은 300 개의 버그입니다. 이것은 웹 애플리케이션을 구조화하는 매우 일반적인 방법입니다.

또 다른 설계 원칙은 데이터베이스에 저장하기 전에 모든 데이터를 삭제하여 데이터베이스에 저장된 데이터가 모든 그럴듯한 HTML 컨텍스트 (HTML, 속성, CSS, Javascript)로 출력하기에 안전하다는 것을 알 수 있도록하는 것입니다. 이것이 당신의 프로그래머가 따르는 규율이라면, 당신이 알고 싶은 것은 코드에 데이터를 먼저 인코딩/이스케이프/정리 화하지 않고 데이터베이스에 저장하는 위치가 있는지 여부입니다. 이 경우 버그가 하나이거나 버그가 많을 수 있습니다.

보다 일반적인 디자인 원칙은 데이터베이스의 각 필드에 대해 다른 불변성을 갖는 것입니다. 일부는 데이터베이스에 저장하기 전에 사전 위생 처리되었습니다 (그리고 다른 컨텍스트에 대해 : 예를 들어 한 필드에 사전 이스케이프되거나 신뢰할 수있는 HTML이 포함될 수 있음) , 다른 하나는 자바 스크립트에 포함하기에 적합한 사전 이스케이프 된 문자열을 보유 할 수 있으며, 일부는 그렇지 않았으며 출력 측에서 이스케이프/정리 화되어야합니다. 이 경우, 발견 한 XSS 취약성과 관련된 데이터베이스의 특정 필드에 대해 프로그램이 유지하고있는 불변성을 살펴 봐야합니다.

네 번째 접근 방식, 그리고 아마도 가장 일반적인 접근 방식은 규율이 전혀없는 것입니다. 이것은 보안에 나쁜 소식입니다.

그래서 저는 소프트웨어 개발자가 XSS를 방어하기 위해 체계적인 전략을 채택했는지 이해하려고 노력하는 것부터 시작해야한다고 생각합니다. 그들이 체계적인 전략을 채택하지 않았다면 근본 문제가 있습니다 (몇 가지 버그를보고 할 수는 있지만 XSS에 대한 체계적인 방어가 부족하다는 것입니다). 그들이 체계적인 전략을 채택했다면, 그 전략이 무엇인지, 그리고 의도 된 불변이 무엇인지 알아 내면 유용한 버그 보고서를 작성하는 더 나은 위치에있게 될 것입니다.

1
D.W.