이 새로운 ASP.NET 보안 취약점은 얼마나 심각하며 어떻게 해결할 수 있습니까?

방금 ASP.NET에서 새로 발견 된 보안 취약점에 대해 인터넷에서 읽었습니다. 자세한 내용은 여기를 참조하십시오.

문제는 ASP.NET이 AES 암호화 알고리즘을 구현하여 이러한 응용 프로그램이 사용자 세션 중에 정보를 저장하기 위해 생성하는 쿠키의 무결성을 보호하는 방식에 있습니다.

이것은 약간 모호하지만 여기에 더 무서운 부분이 있습니다.

공격의 첫 단계는 수천 건의 요청이 필요하지만 성공하면 공격자가 비밀 키를 받으면 완전히 은밀합니다. 필요한 암호 지식은 매우 기본적입니다.

전반적으로, 나는 이것이 정말로 심각한 지 알기 위해 보안 / 암호화 주제에 익숙하지 않습니다.

따라서 모든 ASP.NET 개발자 는 몇 초 안에 ASP.NET 웹 사이트를 소유 할 수있는 이 기술을 두려워 해야합니까?

이 문제는 평균 ASP.NET 개발자에게 어떤 영향을 줍니까? 그것은 우리에게 전혀 영향을 미칩니 까? 실제로이 취약점의 결과는 무엇입니까? 그리고 마지막으로 :이 취약점을 방지하는 해결 방법이 있습니까?

답변 주셔서 감사합니다!

편집 : 내가받은 응답을 요약 해 드리겠습니다

따라서 이것은 기본적으로 "패딩 오라클"유형의 공격입니다. @Sri 는 이러한 유형의 공격이 무엇을 의미하는지에 대한 훌륭한 설명을 제공했습니다. 이 문제에 대한 충격적인 비디오가 있습니다!

이 취약점의 심각성에 관하여 : 예, 실제로 심각합니다. 공격자는 응용 프로그램의 시스템 키를 알 수 있습니다. 따라서 그는 매우 원치 않는 일 을 할 수 있습니다 .

• 앱의 머신 키를 소유 한 공격자는 인증 쿠키를 해독 할 수 있습니다.
• 그보다 더 나쁜 것은 사용자 이름으로 인증 쿠키 를 생성 할 수 있다는 것입니다 . 따라서 그는 사이트의 모든 사람으로 나타날 수 있습니다. 응용 프로그램은 귀하 또는 귀하의 이름으로 인증 쿠키를 생성 한 해커를 구별 할 수 없습니다.
• 또한 이전 쿠키 만큼 위험하지는 않지만 세션 쿠키 를 해독 (및 생성) 할 수도 있습니다 .
• 그렇게 심각하지는 않습니다 : 그는 페이지의 암호화 된 ViewState를 해독 할 수 있습니다. (ViewState를 사용하여 자신감있는 데이터를 저장하는 경우 어쨌든 그렇게하지 않아야합니다!)
• 예상치 못한 공격 : 머신 키에 대한 지식으로 공격자 는 웹 응용 프로그램에서 임의의 파일을 다운로드 할 수 있습니다. ( Web.Config 등 포함 )

여기에 내가 가진 좋은 관행의 무리입니다 하지 않는 문제를 해결하지만, 도움이 웹 애플리케이션의 일반적인 보안을 향상은.

• 보호 된 구성으로 중요한 데이터를 암호화 할 수 있습니다
• HTTP 전용 쿠키 사용
• DoS 공격 방지

이제이 문제에 초점을 맞추겠습니다.

• Scott Guthrie는 자신의 블로그에 해당 항목을 게시했습니다.
• 취약점에 대한 ScottGu의 FAQ 블로그 게시물
• 취약점에 대한 ScottGu의 업데이트
• Microsoft는 이에 대한 보안 권고를 받았습니다
• 취약점 이해
• 취약점에 대한 추가 정보

해결책

• customErrors를 활성화하고 모든 오류 가 리디렉션 되는 단일 오류 페이지를 만듭니다 . 네, 심지어 404 . (ScottGu에 따르면이 공격에는 404와 500을 구분하는 것이 필수적이라고합니다.) 또한 무작위 지연을 유발하는 코드를 Application_Error넣거나 Error.aspx입력 하십시오 . 임의의 숫자를 생성하고 Thread.Sleep을 사용하여 오랫동안 잠자기 상태로 만듭니다. 그러면 공격자가 서버에서 정확히 무슨 일이 있었는지 결정할 수 없습니다.
• 어떤 사람들은 3DES로 다시 전환하는 것이 좋습니다. 이론적으로 AES를 사용하지 않으면 AES 구현에서 보안 취약점이 발생하지 않습니다. 결과적으로 이것은 권장되지 않습니다 .

다른 생각들

• 것으로 보인다 되지 모두 해결 방법이 좋은 충분하다 생각합니다.

내 질문에 답변 한 모든 사람에게 감사합니다. 이 문제뿐만 아니라 일반적으로 웹 보안에 대해 많은 것을 배웠습니다. @Mikael의 답변을 수락 된 것으로 표시했지만 다른 답변도 매우 유용합니다.

자신을 보호하려면 어떻게해야합니까?

[2010-09-29 업데이트]

Microsoft 보안 게시판

수정 사항을 참조한 KB 기사

ScottGu 는 다운로드 링크가 있습니다

[2010-09-25 업데이트]

수정을 기다리는 동안 어제 ScottGu 는 사용자 정의 URLScan 규칙으로 사이트를 보호하기위한 추가 단계를 추가하는 방법에 대한 업데이트 를 게시합니다 .

또한 공격자가 추가 된 공격 정보에 대한 응답의 타이밍 을 막을 수 있도록 오류 페이지에 임의의 시간 절전 모드 를 추가하십시오.

web.config에서

<configuration>
 <location allowOverride="false">
   <system.web>
     <customErrors mode="On" defaultRedirect="~/error.html" />
   </system.web>
 </location>
</configuration>

이렇게하면 오류가 200 상태 코드와 함께 반환 된 사용자 정의 페이지로 리디렉션됩니다. 이런 방식으로 공격자는 추가 공격에 필요한 정보를 찾기 위해 오류 코드 또는 오류 정보를 볼 수 없습니다.

customErrors mode="RemoteOnly""실제"클라이언트를 리디렉션하므로을 설정하는 것도 안전합니다 . localhost에서 검색하는 경우에만 내부 .Net 오류가 표시됩니다.

중요한 부분은 모든 오류가 동일한 오류 페이지를 반환하도록 구성되어 있는지 확인하는 것입니다. 이를 위해서는 섹션 에서 defaultRedirect속성 을 명시 적으로 설정하고 <customErrors>상태 별 코드가 설정되지 않아야합니다.

무슨 일이야?

공격자가 언급 된 익스플로잇을 사용하는 경우 웹 응용 프로그램 내에서 내부 파일을 다운로드 할 수 있습니다. 일반적으로 web.config는 대상이며 데이터베이스 연결 문자열에 로그인 정보와 같은 민감한 정보를 포함하거나 누군가가 원하지 않는 자동 SQL-Express 데이터베이스에 대한 링크를 포함 할 수 있습니다. 그러나 모범 사례를 따르는 경우 보호 된 구성 을 사용하여 web.config의 모든 중요한 데이터를 암호화합니다.

참조 링크

http://www.microsoft.com/technet/security/advisory/2416728.mspx 에서 취약점에 대한 Microsoft의 공식 의견을 읽어보십시오 . 특히이 문제에 대한 구현 세부 사항은 "해결 방법"부분입니다.

또한 웹 서버에서 취약한 ASP.Net 앱을 찾는 스크립트 를 포함하여 ScottGu의 블로그 에 대한 정보도 있습니다 .

"Padding Oracle Attacks 이해"에 대한 설명은 @ sri 's answer를 참조하십시오 .

기사에 대한 의견 :

Rizzo와 Duong이 ASP.NET 앱에 대해 구현 한 공격에는 웹 사이트의 암호화 구현에 암호문을 보낼 때 텍스트를 해독 할뿐만 아니라 발신자에게 암호문의 패딩 여부에 대한 메시지를 제공 하는 오라클이 있어야합니다. 유효합니다 .

패딩이 유효하지 않으면 발신자가받는 오류 메시지는 사이트의 암호 해독 프로세스 작동 방식에 대한 정보를 제공합니다.

공격이 작동하려면 다음 사항이 충족되어야합니다.

• 응용 프로그램은 유효하지 않은 패딩에 대한 오류 메시지를 제공해야합니다.
• 누군가 암호화 된 쿠키 또는 viewstate를 변조해야합니다

따라서 앱에서 "문제가 발생했습니다. 다시 시도하십시오" 와 같이 사람이 읽을 수있는 오류 메시지를 반환 하면 매우 안전해야합니다. 기사에 대한 의견을 조금 읽으면 소중한 정보를 얻을 수 있습니다.

• 암호화 된 쿠키에 세션 ID 저장
• 실제 데이터를 세션 상태로 저장 (db에 유지)
• 오류를 반환하기 전에 사용자 정보가 잘못되었을 때 무작위 대기를 추가하여 시간을 정할 수 없습니다

이렇게하면 하이재킹 된 쿠키를 사용하여 더 이상 존재하지 않거나 무효화 된 세션을 검색 할 수 있습니다.

Ekoparty 컨퍼런스에서 실제로 발표되는 내용을 보는 것이 흥미로울 것이지만 지금은이 취약점에 대해 너무 걱정하지 않습니다.

패딩 Oracle 공격 이해

매개 변수가 쿠키인지, URL 매개 변수인지 또는 중요하지 않은지 여부에 관계없이 애플리케이션이 암호화 된 문자열을 매개 변수로 승인한다고 가정합니다. 응용 프로그램이 그것을 해독하려고 할 때 3 가지 가능한 결과가 있습니다.

1. 결과 1 : 암호화 된 문자열이 올바르게 해독되어 응용 프로그램에서 이해할 수있었습니다. 암호화 된 문자열이 10 자리 계정 번호 인 경우 해독 후 응용 프로그램에서 "abcd1213ef"가 아닌 "1234567890"과 같은 것을 발견했습니다.

2. 결과 2 : 패딩은 정확했지만 해독 후 얻은 문자열은 앱이 이해할 수없는 횡설수설했습니다. 예를 들어 문자열은 "abcd1213ef"로 해독되었지만 앱은 숫자 만 기대하고있었습니다. 대부분의 앱은 "잘못된 계정 번호"와 같은 메시지를 표시합니다.

3. 결과 3 : 패딩이 잘못되어 응용 프로그램에서 일종의 오류 메시지가 발생했습니다. 대부분의 앱은 "일부 오류가 발생했습니다"와 같은 일반적인 메시지를 표시합니다.

Padding Oracle 공격이 성공하려면 공격자는 수천 건의 요청 을 수행 할 수 있어야하며 오류없이 응답을 위의 3 개 버킷 중 하나로 분류 할 수 있어야합니다.

이 두 가지 조건이 충족되면 공격자는 결국 메시지를 해독 한 다음 원하는대로 메시지를 다시 암호화 할 수 있습니다. 그것은 단지 시간 문제입니다.

그것을 막기 위해 무엇을 할 수 있습니까?

1. 가장 간단한 것-민감한 것은 클라이언트에게 보내거나 암호화하거나 암호화하지 않아야합니다. 서버에 보관하십시오.

2. 위 목록의 결과 2와 결과 3 이 공격자 와 정확히 동일 하게 나타나는지 확인하십시오 . 서로를 알아낼 방법이 없어야합니다. 그러나 이것은 쉬운 일이 아닙니다. 공격자는 일종의 타이밍 공격을 사용하여 차별 할 수 있습니다.

3. 마지막 방어선으로 웹 응용 프로그램 방화벽이 있어야합니다. 패딩 오라클 공격은 한 번에 1 비트 씩 변경되는 거의 비슷한 모양의 여러 요청을 만들어야하므로 WAF가 그러한 요청을 포착하고 차단할 수 있어야합니다.

추신 : Oracle 블로그 패딩에 대한 좋은 설명은 이 블로그 게시물 에서 찾을 수 있습니다 . 면책 조항 : 그것은 내 블로그가 아닙니다.

내가 읽은 것부터 지금까지 ...

이 공격을 통해 누군가는 스니핑 된 쿠키를 해독 할 수 있습니다.이 쿠키에는 은행 잔고와 같은 중요한 데이터가 포함될 수 있습니다

계정에 이미 로그인 한 사용자의 암호화 된 쿠키가 필요합니다. 그들은 또한 쿠키에서 데이터를 찾아야합니다-개발자가 쿠키에 중요한 데이터를 저장하지 않기를 바랍니다 :). 그리고 asp.net이 로그인 쿠키에 데이터를 저장하지 못하게하는 방법이 있습니다.

브라우저 데이터를 손에 넣지 않으면 온라인 사용자의 쿠키를 어떻게 얻을 수 있습니까? 아니면 IP 패킷을 스니핑합니까?

이를 방지하는 한 가지 방법은 쿠키를 SSL 암호화없이 전송하지 못하게하는 것입니다.

<httpCookies httpOnlyCookies="true" requireSSL="true" />

또한 쿠키에 역할을 저장하지 못하게하는 방법도 있습니다.

<roleManager enabled="true" cacheRolesInCookie="false">

이제 일반 페이지에 안전하지 않은 쿠키에 대해서는 사용자가 남긴 일과하지 말아야 할 일, 신뢰할 수있는 방법, 수행 할 수있는 추가 점검 (예 : IP에 변경 사항이있는 경우)에 대해 더 생각해야합니다. 보안 페이지에서 다시 로그인 할 때까지 신뢰를 중지하십시오.

참조 :
일부 해커가 사용자의 쿠키를 훔쳐 웹 사이트에서 해당 이름으로 로그인 할 수 있습니까?

공격 이 어디서 왔는지 확인하고 정보를 제공하지 않는 방법. 여기에 패딩이 유효하지 않고 동시에 공격자를 추적하기 위해 로깅하는 것을 방지하는 간단한 방법을 썼습니다 : CryptographicException : 패딩이 유효하지 않으며 제거 할 수 없으며 viewstate MAC의 유효성 검사에 실패했습니다

공격자를 추적하는 방법은 패딩이 유효하지 않은지 확인하는 것입니다. 간단한 절차를 통해 추적하고 차단할 수 있습니다. 키를 찾으려면 페이지에서 수천 번의 호출이 필요합니다!

업데이트 1.

KEY를 찾고 데이터를 해독한다고 가정하고 위의 코드 에서 트랩을 말한 것처럼 viewstate를 확인하는 도구를 다운로드했습니다 . 내 테스트 에서이 도구는 수정해야 할 것이 더 많습니다. 예를 들어 압축 뷰 상태를 그대로 스캔 할 수 없으며 테스트에서 충돌이 발생합니다.

어떤 하나의 시도가이 도구 또는이 방법을 사용하는 경우 위의 코드는 그들을 추적 할 수 있습니다 당신은 밖으로 이와 같은 간단한 코드와 페이지를 차단할 수 있습니다 "서비스의 방지 거부 (DOS)" , 또는 거부를 방지하기위한 코드와 같은 서비스 .

업데이트 2

그것은 내가하는 것이 지금까지 읽은 것과 같다 (가) 해당이 오류에 대한 정보 등을주지 할 필요가 정말 생각 , 그냥 사용자 지정 오류 페이지를 배치하고 경우에 당신은 만들 수 있습니다처럼이 페이지에 임의의 지연.

이 문제에 대한 매우 흥미로운 비디오 입니다.

따라서 위의 모든 사항은 더 많은 보호를 위해 측정되지만이 특정 문제에 100 % 필요하지는 않습니다. 예를 들어 ssl 쿠키를 사용하는 것은 snif 문제를 해결하고, 쿠키에 역할을 캐시하지 말고 큰 쿠키를 보내고 다시 가져 오지 않고, 코드를 해독 할 준비가 된 일부 사용자를 피하여 관리자 역할을 설정하십시오. 그 쿠키.

viewstate는 공격을 찾기위한 단 하나의 조치를 더 추적합니다.

다음 은 MS 응답입니다. 그것은 모두 "사용자 정의 오류 페이지 사용"으로 요약되며 아무런 단서도 제공하지 않습니다.

편집
여기 scottgu의 더 자세한 정보가 있습니다.

http://weblogs.asp.net/scottgu/archive/2010/09/18/important-asp-net-security-vulnerability.aspx 에서 토론에서 가져온 ScottGu의 응답 추가

customErrors 대신 custom IHttpModule이 영향을 받습니까?

Q : web.config에 선언 된 요소가없고 대신 섹션 안에 IHttpModule이 있습니다. 이 모듈은 오류를 기록하고 검색 페이지 (404) 또는 오류 페이지 (500)로 리디렉션합니다. 내가 취약한가?

A : 검색 페이지로 항상 리디렉션되도록 모듈을 임시로 업데이트하는 것이 좋습니다. 이 공격이 작동하는 방법 중 하나는 404와 500 오류 사이의 차별화를 찾는 것입니다. 항상 동일한 HTTP 코드를 반환하고 같은 장소로 보내는 것이이를 차단하는 한 가지 방법입니다.

패치가이 문제를 해결하기 위해 나올 때이 작업을 수행 할 필요가 없으며 이전 동작으로 되돌릴 수 있습니다. 그러나 현재로서는 404와 500을 클라이언트와 차별화하지 않는 것이 좋습니다.

404 및 500 오류에 대해 다른 오류를 계속 사용할 수 있습니까?

Q : 위에서 설명한 원칙을 위반하지 않고 오류시 기본 리디렉션 외에 사용자 정의 404 페이지를 정의 할 수 있습니까?

A : 아니요-실제 수정 사항에 대한 패치를 릴리스 할 때까지 모든 오류를 균일화하는 위의 해결 방법을 권장합니다. 이 공격이 작동하는 방법 중 하나는 404와 500 오류 사이의 차별화를 찾는 것입니다. 항상 동일한 HTTP 코드를 반환하고 동일한 장소로 보내는 것이이를 차단하는 한 가지 방법입니다.

패치가이 문제를 해결하기 위해 나올 때이 작업을 수행 할 필요가 없으며 이전 동작으로 되돌릴 수 있습니다. 그러나 지금 당장은 클라이언트와 404와 500을 구분해서는 안됩니다.

이것은 어떻게 web.config의 노출을 허용합니까?

Q : web.config 노출을 어떻게 허용합니까? 이것은 ViewState의 해독 만 가능하게하는 것 같습니다. 정보 공개를 허용하는 또 다른 관련 취약점이 있습니까? 무슨 일이 일어나고 있는지 더 잘 설명하기 위해 공격에 대해 자세히 설명하는 백서가 있습니까?

A : 공개적으로 나타난 공격은 파일 (일반적으로 javascript 및 css)을 다운로드 할 수있는 ASP.NET의 기능에 의존하며 요청의 일부로 전송되는 키로 보호됩니다. 불행히도 키를 위조 할 수있는 경우이 기능을 사용하여 응용 프로그램의 web.config 파일을 다운로드 할 수 있지만 응용 프로그램 외부의 파일은 다운로드 할 수 없습니다. 우리는 분명히 이것에 대한 패치를 릴리스 할 것입니다. 그때까지 위의 대안이 공격 경로를 닫습니다.

편집 : http://weblogs.asp.net/scottgu/archive/2010/09/20/frequently-asked-questions-about-the-asp-net-security-vulnerability.aspx 의 두 번째 블로그 게시물에 추가 FAQ가 있습니다 .

IMO, 이에 대한 전체적인 예방은 없으며 사례별로 처리해야합니다.

http://www.onpreinit.com/2010/09/aspnet-vulnerability-workaround-flawed.html

몇 가지 중요한 링크 :

• MS의 보안 권고 2416728 (이것은 공식 정보입니다)
• MS 보안 연구 및 방어 팀의 추가 정보
  • "ASP.NET 취약점 이해"(2010-09-17)
  • "ASP.NET 취약점에 대한 추가 정보"(2010-09-20)
• Scott Gu : "중요 : ASP.NET 보안 취약성"(2010-09-18)

[이 문제의 심각성 측면에 대한 답변 (발표 된 내용과 해결 방법은 다른 답변에 포함되어 있음)]

공격중인 키는보기 상태 및 세션 쿠키를 모두 보호하는 데 사용됩니다. 일반적으로이 키는 웹 응용 프로그램의 각 새 인스턴스와 함께 ASP.NET에 의해 내부적으로 생성됩니다. 이것은 작업자 프로세스의 수명에 대한 손상 범위를 제한 할 것입니다. 물론 바쁜 응용 프로그램의 경우 며칠이 될 수 있습니다 (즉, 제한이 많지 않습니다). 이 시간 동안 공격자는 ViewState에 값을 변경 (또는 주입)하고 세션을 변경할 수 있습니다.

더 심각하게 세션이 작업자 프로세스 수명을 연장하거나 웹 팜 (팜의 모든 인스턴스가 모든 사용자 세션을 처리 할 수 ​​있음)을 허용하려면 키를 하드 코딩해야합니다 web.config.

[...]
  <system.web>
    <machineKey
        decryption="AES"
        validation="SHA1"
        decryptionKey="57726C59BA73E8A4E95E47F4BC9FB2DD"
        validationKey="158B6D89EE90A814874F1B3129ED00FB8FD34DD3"
      />

물론 새로 만든 키는 다음 PowerShell을 사용하여 Windows 암호화 난수 생성기에 액세스합니다.

$rng = New-Object "System.Security.Cryptography.RNGCryptoServiceProvider"
$bytes = [Array]::CreateInstance([byte], 20)
$rng.GetBytes($bytes)
$bytes | ForEach-Object -begin { $s = "" } -process { $s = $s + ("{0:X2}" -f $_) } -end { $s}

유효성 검사에는 배열 길이 20을 사용하고 암호 해독 키에는 16을 사용합니다.

특정 오류가 발생하지 않도록 공개 오류 페이지를 수정하는 것 외에도 위의 키를 변경하거나 작업자 프로세스가 잠시 실행 된 경우주기 프로세스를 수행하는 것이 좋습니다.

[2010-09-21 편집 : 맨 위에 링크 추가]

이 문제에 대한 추가 조사를 마친 후 블로그 에이 내용을 게시했습니다 . 나는 그들이 인증 쿠키를 위조하는 것만 큼 중요한 이유를 밝혀내는 것이 중요하다고 생각합니다.

몇 가지 사실을 바로 알고 싶습니다.

1. 공격은 컴퓨터 키를 직접 얻지 못하게합니다. 즉, 메시지를 해독하고 새 메시지를 다시 암호화 / 수정할 수 있기 때문에 거의 비슷합니다.
2. 실제 키를 얻는 방법은 1과 같이 다시 / 암호화를 수정하고 web.config를 얻는 기능을 사용하는 것입니다. 불행히도 일부는 이러한 키를 사이트 수준 (다른 토론)의 web.config에 넣은 이유가 있으며 샘플 비디오에서는 기본 키인 DotnetNuke의 이점이 있습니다.
3. web.config를 얻으려면 webresources.axd 및 / 또는 scriptresources.axd를 사용하고 있음을 나타냅니다. 나는 이것들이 임베디드 리소스에서만 작동한다고 생각했지만 그것은 사실이 아닙니다.
4. 앱이 asp.net MVC 인 경우 webresources.axd 및 / 또는 scriptresources.axd가 실제로 필요하지 않으므로 해당 기능을 끌 수 있습니다. 우리는 또한 viewstate를 사용하지 않습니다. 즉, 다른 asp.net 기능 중 하나가 해결 방법으로 다른 정보를 제공하는지 여부는 확실하지 않습니다. 즉, 패딩이 유효하지 않은 인증 티켓에 유효한 결과를 패딩하는 동안 패딩이 잘못된 결과를 제공하는지 알 수 없습니다 (모름 경우에 따라) 세션 쿠키에도 동일한 분석이 적용됩니다.
5. asp.net 회원 제공 업체는 쿠키에서 '캐시'역할을 수행합니다.

약 1, 암호화 된 메시지는 제어 할 수없는 값을 해독하는 메시지에 1 블록이 있기 때문에 메시지의 어딘가에 작은 가비지 조각을 허용 해야하는 100 % 임의의 필요는 없습니다.

마지막 으로이 문제는 ms 가이 경우 자체 지침을 따르지 않은 결과라고 말하고 싶습니다. 기능은 변조 방지 인 클라이언트에게 전송 된 것에 의존합니다.

더 :

무시 된 인증 티켓에 유효한 결과를 채우는 동안 패딩에 잘못된 결과가 오류로 표시되는지 여부를 알 수 없습니다 (대소 여부는 알 수 없음) ... 동일한 분석이 세션 쿠키에 적용되어야합니다.

인증 쿠키는 서명되어 있으며, 논문의 정보에서 실제 키에 도달하지 않으면 (인증 쿠키를 위조하기 전에 비디오에서와 같이) 서명 된 쿠키를 생성 할 수 없습니다.

Aristos가 언급했듯이 쿠키의 세션 ID에 대해서는 사용자 세션에 대해 무작위이므로 대상 보안 수준의 사용자로부터 스니핑하고 해당 세션이 활성화되는 동안 크랙해야합니다. 그럼에도 불구하고 사용자 작업을 할당 / 권한 부여하기 위해 인증에 의존하는 경우 영향은 최소화됩니다. 해당 앱에서 세션이 사용되는 데 많은 영향을 미칩니다.

이 버그에 대한 패치는 Windows Update에서 릴리스되었습니다 : http://weblogs.asp.net/scottgu/archive/2010/09/30/asp-net-security-fix-now-on-windows-update.aspx

Asp.Net MVC도이 문제의 영향을받습니다 (Sharepoint 등).

MVC에 대한 수정 사항은 여기에서 다루었습니다. ASP.NET MVC는 오라클 패딩 공격에 취약합니까?