ProgramingTip

악용 가능한 C # 함수

bestdevel 2020. 11. 3. 08:21

악용 가능한 C # 함수

이 질문은 Exploitable PHP Functions 와 유사합니다 .

오염 된 데이터는 사용자 또는보다 직접 공격자가 제공합니다. 오염 된 변수가 싱크 함수에 도달하면 취약성이 있습니다. 예를 들어 SQL 쿼리를 실행하는 함수는 싱크이고 GET / POST 변수는 오염의 원인입니다.

C #의 모든 싱크 함수는 무엇입니까? 취약성 또는 소프트웨어 약점 을 도입하는 기능을 찾고 있습니다. 특히 원격 코드 실행에 관심이 있습니다. 해커가 영향을주고 싶어하는 불쾌한 기능을 포함하는 전체 / 라이브러리가 있습니까? 사람들은 어떻게 실수로 위험한 C # 코드를 만들까요?

웹 기반 건물에서 C # (더 일반적으로 ASP.NET)은 일반적으로 다음 항목 ( OWASP Top 10 2013에 항목)에 취약합니다 . 나는 당신이 주로 싱크 함수에 관심이있는 것으로 알고 있는데, 그중 일부를 다루지 만 사람들이 실수로 위험한 C # 코드를 어떻게 만들 었는지 여부에 따라 여기에있는 것을 제공했습니다.

A1- 주사

SQL

공유 연결로 쿼리 생성.

var sql = "SELECT * FROM UserAccount WHERE Username = '" + username "'";
SqlCommand command = new SqlCommand(sql , connection);
SqlDataReader reader = command.ExecuteReader();

종종 이것은 매개 변수화 된 쿼리 로 해결할 수 있지만 IN보기 조건을 사용하는 경우 현재 문자열 연결 없이는 불가능합니다 .

LDAP

다음과 같은 코드

searcher.Filter = string.Format("(sAMAccountName={1})", loginName);

응용 프로그램을 만들 수 있습니다. 여기에 더 많은 정보가 있습니다 .

OS 제공

이 코드는 두 번째 요청한 변수가 여러 명령을 일괄 처리하기 Process.Start위해 &문자를 사용하여 추가 명령을 많은 수 있기 때문에 두 번째 요청 합니다.

string strCmdText= @"/C dir c:\files\" + Request.QueryString["dir"];
ProcessStartInfo info = new ProcessStartInfo("CMD.exe", strCmdText);
Process.Start(info);

예 : foldername && ipconfig

A2-Broken 인증 및 세션 관리

로그 아웃

기본 양식 인증 로그 아웃 방법은 서버 측을 업데이트하지 않고 계속 사용할 수 있습니다.

SignOut 메서드를 호출하면 양식 인증 쿠키 만 제거됩니다. 웹 서버는 나중에 사용할 수 있습니다. 이로 악의적 인 사용자가 유효한 폼 인증 쿠키를 얻을 경우 사이트가 재생 공격에 취약 해집니다.

인증에 세션 상태 사용

세션 고정 사용자가 사용하는 경우에 전용이 적합한 수있는 인증 세션 상태 .

A3- 교차 사이트 스크립팅 (XSS)

Response.Write(및 바로 가기 <%= =>)는 개발자가 출력을 HTML로 인코딩하는 것을 기억하지 않는 기본적으로 부담합니다. <%:일부 개발자는이 값을 사용하여 공격자가 여전히 이스케이프 할 수있는 JavaScript에 값을 삽입 할 수 있습니다. 최신 바로 가기 HTML이 기본적으로 인코딩됩니다. 최신 Razor 엔진을 사용하지만이를 사용 하기 어렵습니다.

var name = '@Html.Raw(HttpUtility.JavaScriptStringEncode(Model.Name))';

ASP.NET은 기본적으로 요청 유효성 검사를 활성화 하여 쿠키, 쿼리 고급 및 악성 일 수있는 POST 데이터 (예 : HTML 태그)의 입력을 차단합니다. 이는 특히 특정 앱을 사용하여 다른 입력에 잘 사용하여 사용할 수 있지만 다른 기술을 사용하여 사용할 앱과 같은 배포 코드가 여전히 출력 될 앱과 있습니다 ... 또 다른 약점은 데이터가 속성 값 복제되는 것입니다. 예 :

<%
alt = Request.QueryString["alt"];
%>
<img src="http://example.com/foo.jpg" alt="<%=alt %>" />

이는 요청 유효성 검사를 트리거하지 않고 악용 될 수 있습니다.

만약 altIS

" onload="alert('xss')

그러면

<img src="http://example.com/foo.jpg" alt="" onload="alert('xss')" />

이전 버전의 .NET에서는 개발자가 일부 기본 컨트롤을 사용하여 출력이 코드 인코딩 확인하는 것이 약간의 지뢰밭을 사용 합니다.

안타깝게도 데이터 바인딩 구문에는 아직 인코딩 구문이 포함되어 있지 않습니다. 다음 버전의 ASP.NET에서 제공 될 예정입니다.

예 : 취약하지 발생 :

  <asp:Repeater ID="Repeater1" runat="server">
    <ItemTemplate>
      <asp:TextBox ID="txtYourField" Text='<%# Bind("YourField") %>'
        runat="server"></asp:TextBox>
    </ItemTemplate>
  </asp:Repeater>

취약 :

<asp:Repeater ID="Repeater2" runat="server">
  <ItemTemplate>
    <%# Eval("YourField") %>
  </ItemTemplate>
</asp:Repeater>

A4- 안전하지 않은 직접 개체 참조

MVC 모델 바인딩을 사용 하면 POST 데이터 에 추가 된 매개 변수를 데이터 모델에 매핑 할 수 있습니다. 개발자가 악의적 인 사용자가 일반적으로 사용되는 변수를 수 있지만 사실을 개발자가 인식하지 않습니다. Bind은 사용할 수 속성 있습니다 이를 방지 .

A5- 보안 잘못된 구성

응용 프로그램의 보안을 약화시킬 수있는 많은 구성 옵션이 있습니다. 설정 예를 들어 customErrors에 On또는 추적을 가능하게한다.

ASafaWeb 과 같은 스캐너 는 잘못된 잘못된 구성을 확인할 수 있습니다.

A6- 민감한 데이터 노출

기본 해싱

ASP.NET의 기본 암호 해싱 방법은 최선이 아닙니다.

HashPasswordForStoringInConfigFile () -솔트가 추가되지 않은 일반 비밀번호를 해시하는 데 사용되는 경우에도 좋지 않을 수 있습니다.
.NET 4의 ASP.NET 멤버 자격 공급자에 관한 " 우리의 암호 해싱에는 옷이 없습니다 "기사 .

A7- 누락 된 기능 수준 액세스 제어

URL 액세스 제한 실패

통합 파이프 라인 모드에서 .NET은 모든 요청을 볼 수있는 핸들은 .NET이 아닌 리소스 (예 : .js및 이미지)에 각 요청을 승인 할 수 있습니다 . 그러나 클래식 모드에서 실행중인 응용 프로그램은 .NET에서 파일에 대한 요청 만 확인 .aspx하는 다른 파일이 실수로 보안 해제 될 수 있습니다. 차이점에 대한 자세한 내용은 이 답변 을 참조하십시오 .

예를 들어 해결 방법www.example.com/images/private_photograph_user1.jpg 이 제안 클래식 모드에서 실행되는 응용 프로그램에서 가능성이 더있을 것 입니다.

A8-CSRF (교차 사이트 요청 위조)

레거시 웹 양식 애플리케이션은 공격자가 View State 및 Event Validation 값 을 위조하도록 요구하기 때문에 일반적으로 CSRF에 대해 더 안전 하지만 개발자가 위조 방지 토큰을 수동으로 구현하지 않는 한 최신 MVC 애플리케이션은 취약 할 수 있습니다 . 참고로 웹 양식이 취약하지 않다고 말하는 것이 아니라 몇 가지 가지 기본적인 변수 것 전달하는 것이 더 어렵다는 것입니다.하지만 사용자 키 를보기 상태 값에 통합하는 것과 같은 수정 사항이 있습니다 .

EnableEventValidation 속성이 true로 설정되면 ASP.NET은 해당 컨트롤에서 제어 한 사용자 인터페이스에서 시작된 이벤트의 유효성을 검사합니다. 컨트롤은 이벤트 중에 이벤트를 등록한 다음 포스트 백 또는 처리 중에 이벤트의 유효성을 검사합니다. 예를 들어 페이지가 수신 될 때 목록 컨트롤에 1, 2 또는 3 번호가 지정된 옵션이 포함되어 있고 옵션 번호가 4를 지정하는 포스트 백 요청이 수신되면 ASP.NET에서 예외가 발생합니다. ASP.NET의 모든 이벤트 기반 컨트롤은 기본적으로 기능을 사용합니다.

[EnableEventValidation] 기능은 무단 또는 악의적 인 백 요청 및 복수의 위험을 포스트 전달합니다. 이벤트 유효성 검사를하지 않는 것이 좋습니다.

A10- 전파되지 않음-리디렉션 및 전달

다음과 같은 코드 추가

Response.Redirect(Request.QueryString["Url"]);

사이트가 취약 해집니다. 링크가 포함 된 사용자에게 피싱 이메일을 보내 공격을 시작할 수 있습니다. 사용자가 경계하는 경우 클릭하기 전에 URL의 도메인을 두 번 확인했을 수 있습니다. 그러나 도메인이 사용자가 신뢰하는 도메인과 일치하므로 페이지가 사용자를 공격자의 도메인으로 리디렉션한다는 사실을 인식하지 못한 채 링크를 클릭합니다.

Url허용 된 상대 URL 또는 허용 된 도메인 및 페이지 중 하나에 대한 절대 URL인지 확인하기 위해 유효성 검사를 수행해야 합니다. /Logout.aspx예를 들어 누군가가 사용자를 리디렉션하지 않는지 확인할 수 있습니다 . 공격자가에 직접 연결하는 것을 막을 수는 없지만 http://www.example.com/Logout.aspx리디렉션을 사용하여 URL을 숨길 수 있으므로 사용자가 액세스중인 페이지를 이해하기 어렵습니다 ( http://www.example.com/Redirect.aspx?Url=%2f%4c%6f%67%6f%75%74%2e%61%73%70%78).

기타

다른 OWASP 범주는 다음과 같습니다.

A9- 알려진 취약점이있는 구성 요소 사용

그중 C # / ASP.NET에만 해당하는 것은 생각할 수 없습니다. 내가 생각하는 경우 내 답변을 업데이트하겠습니다 (귀하의 질문과 관련이 있다고 생각하는 경우).

정규식을 사용하는 모든 것 (특히 RegularExpressionValidator). 이를 확인하려면 정규식을 사용하여 RegularExpressionValidator를 실행하고 ^(\d+)+$유효성을 검사 할 30 자리 숫자와 알파 문자를 제공합니다.

일부 게시물 :

http://msdn.microsoft.com/en-us/magazine/ff646973.aspx
http://www.abemiester.com/abemiester/post/RegEx-DOS-attack-Regular-Expressions-Now-you-have-3-problems.aspx (이것은 내 블로그의 블로그 게시물입니다. MSDN 기사).

이를 정규식 서비스 거부 공격이라고하며 웹 사이트를 무너 뜨릴 수 있습니다.

Process.Start 가장 먼저 떠오르는 것입니다.

나는 WindowsIdentity그리고 많은 System.Security것이 또한 악에 사용될 수 있다고 확신합니다 .

물론 SQL 주입 공격이 있지만 이것이 의미하는 바는 아닙니다 (SQL Server를 통해 원격 실행이 발생할 수 있음).

Process.Start()이미 언급 한 명백한 것 외에도 간접적 착취 가능성이있는 몇 가지 방법을 볼 수 있습니다.

PInvoke를 통해 WinAPI를 호출합니다 CreateProcess().
Assembly.Load()및 기타 과부하를 사용하는 모든 종류의 동적 어셈블리 로딩 메커니즘 . 손상된 어셈블리가 시스템에 도착하여로드 된 경우.
일반적으로 전적으로 신뢰하는 경우.
올바른 권한이 있으면 모든 레지스트리 작업이 위험에 처할 수 있습니다.

그게 지금 생각 나는 전부입니다.

IMO : 악용 가능한 nr 1 기능은 순진 해 보이지만 생각없이 사용하면 매우 위험합니다.

ASP.Net Response.Write또는 바로 가기에서 :

  <%= searchTermFromUser %>

ADO.Net에서 :

string +운영자 :
var sql = "SELECT * FROM table WHERE name = '" + searchTermFromUser + "'"

사용자 (또는 기타 외부 소스)로부터 가져와 다른 시스템이나 다른 사용자에게 전달하는 데이터는 잠재적 인 악용입니다.

사용자로부터 문자열을 가져 와서 HtmlEncode를 사용하지 않고 다른 사용자에게 표시하면 잠재적 인 공격입니다.

사용자로부터 문자열을 받아 SQL을 구성하는 데 사용하면 잠재적 인 SQL 주입입니다.

사용자로부터 문자열을 받아 Process.Start 또는 Assembly.Load에 대한 파일 이름을 계약하는 데 사용하면 원격 실행 취약점입니다.

요점을 알면 위험은 삭제되지 않은 데이터를 사용하는 것에서 비롯됩니다. 사용자 입력을 삭제하지 않고 (예 : HtmlEncode) 외부 시스템에 전달하지 않거나 주입 방지 인터페이스 (예 : SQL 매개 변수)를 사용하지 않는 경우 상대적으로 안전합니다. 가장 순진 해 보이는 방법은 보안 취약점이 될 수 있습니다.

참고 : 쿠키, html 헤더 및 네트워크를 통해 전달되는 기타 모든 것 역시 사용자의 데이터이며 대부분의 경우 데이터베이스의 데이터도 사용자의 데이터입니다.

System.Net, System.XML, System.IO의 많은 것 (URI 및 / 또는 파일 경로를 취하고 실제로 식별하는 리소스를 처리하는 모든 것) System.Reflection, System.Security, System.Web, System .Data 및 System.Threading 네임 스페이스는 현재 실행을 엉망으로 만드는 것 이상의 나쁜 일을 수행하는 데 사용될 수 있기 때문에 위험 할 수 있습니다. 각각을 식별하는 데 시간이 많이 걸립니다.

물론 모든 타사 어셈블리의 모든 방법은 달리 표시 될 때까지 위험한 것으로 간주해야합니다. 다시 더 많은 시간이 소요됩니다.

특히 유익한 접근 방식이라고 생각하지 않습니다. 함수 체크리스트를 생성하는 것은 제한된 라이브러리 또는 C #과 같은 언어를 사용하는 라이브러리에있는 많은 내용이 언어 자체에있는 대규모 언어에서만 실제로 작동합니다.

Process.Start()다른 프로세스를 직접 실행하는 것과 같은 고전적으로 위험한 예가 있지만 분명히 위험하다는 점에서 균형을 이룹니다. 상대적으로 어리 석고 무능한 코더조차도 다른 방법으로 이동하는 데이터를 비위생적으로 남겨두고 사용할 때주의를 기울일 수 있습니다.

That sanitation of data is a more fruitful thing to look at than any list of functions. Is data validated to remove obviously incorrect input (which may be due to an attack, or may simply be a mistake) and is it encoded and escaped in the appropriate way for a given layer (there is too much talk about "dangerous" character sequences, ' never hurt anyone, it's ' not correctly escaped for SQL, that can hurt when it is indeed at a SQL layer - the job required to make sure the data gets in there correctly is the same as that to avoid exploits). Are the layers at which communication with something outside of the code solid. Are URIs constructed using unexamined input, for example - if not you can turn some of the more commonly used System.Net and System.XML methods into holes.

안전하지 않은 코드를 사용하면 포인터와 같은 문제가 발생할 수 있습니다. Microsoft는 안전하지 않은 코드에 대한 좋은 기사를 http://msdn.microsoft.com/en-us/library/aa288474(VS.71).aspx 에서 제공했습니다 .

Reflection.Emit 및 CodeDom

편집 :

스레딩을 사용하는 플러그인 또는 타사 라이브러리를 허용하면 해당 라이브러리 / 플러그인을 별도의 appdomain에로드하지 않는 한 전체 애플리케이션이 다운 될 수 있습니다.

아마도 프레임 워크의 절반은 매우 무서운 기능을 포함하고있을 것입니다. File.WriteAllText()현재 사용자가 액세스 할 수있는 모든 파일을 덮어 쓸 수 있으므로 매우 무섭다고 생각합니다 .

이 질문에 대한 다른 접근 방식은 보안을 관리하는 방법입니다. http://ondotnet.com/pub/a/dotnet/2003/02/18/permissions.html 의 기사 에는 .NET 보안 시스템에 관한 기본 설명이 포함되어 있으며 모든 권한을 포함 하는 System.Security.Permissions 네임 스페이스가 있습니다. 사용할 수 있습니다. 자세한 내용 은 http://msdn.microsoft.com/en-us/library/5ba4k1c5.aspx 를 참조하십시오.

즉, .NET을 사용하면 프로세스가 가질 수있는 권한을 제한 할 수 있습니다 (예 : 디스크의 데이터를 변경하는 메서드 거부). 그런 다음 이러한 권한을 확인하고 프로세스에 권한이 있는지 여부에 따라 조치를 취할 수 있습니다.

단순한 문자열 비교도 문제가 될 수 있습니다.

응용 프로그램이이 String.Compare 작업의 결과를 기반으로 신뢰 결정을 내리면 CurrentCulture를 변경하여 해당 결정의 결과를 뒤집을 수 있습니다.

예제를 살펴보십시오 . 놓치기 쉬운

사용자가 데이터베이스에서 함수 호출에 대한 이름과 매개 변수를 설정할 수있는 코드를 보았습니다. 시스템은 아무것도 확인하지 않고 Reflection을 통해 명명 된 함수를 실행합니다.

참고 URL : https://stackoverflow.com/questions/3940576/exploitable-c-sharp-functions

'ProgramingTip' 카테고리의 다른 글

MySQL에서 "전체 단어 일치"검색 (0)	2020.11.03
URL에서 HTTP 응답 코드를 얻는 가장 좋은 방법은 무엇입니까? (0)	2020.11.03
Twitter Bootstrap 텍스트 필드의 높이가 너무 작습니까? (0)	2020.11.03
유닉스 타임 스탬프가 주어지면 그날의 시작과 끝을 얻는 방법은 무엇입니까? (0)	2020.11.03
XCTest를 사용하는 테스트의 파일 경로에 대한 NSURL (0)	2020.11.03

현재글악용 가능한 C # 함수

bestdevel

악용 가능한 C # 함수

악용 가능한 C # 함수

A1- 주사

SQL

LDAP

OS 제공

A2-Broken 인증 및 세션 관리

로그 아웃

인증에 세션 상태 사용

A3- 교차 사이트 스크립팅 (XSS)

A4- 안전하지 않은 직접 개체 참조

A5- 보안 잘못된 구성

A6- 민감한 데이터 노출

기본 해싱

A7- 누락 된 기능 수준 액세스 제어

URL 액세스 제한 실패

A8-CSRF (교차 사이트 요청 위조)

A10- 전파되지 않음-리디렉션 및 전달

기타

'ProgramingTip' 카테고리의 다른 글

'ProgramingTip'의 다른글

티스토리툴바

악용 가능한 C # 함수

악용 가능한 C # 함수

A1- 주사

SQL

LDAP

OS 제공

A2-Broken 인증 및 세션 관리

로그 아웃

인증에 세션 상태 사용

A3- 교차 사이트 스크립팅 (XSS)

A4- 안전하지 않은 직접 개체 참조

A5- 보안 잘못된 구성

A6- 민감한 데이터 노출

기본 해싱

A7- 누락 된 기능 수준 액세스 제어

URL 액세스 제한 실패

A8-CSRF (교차 사이트 요청 위조)

A10- 전파되지 않음-리디렉션 및 전달

기타

'ProgramingTip' 카테고리의 다른 글

'ProgramingTip'의 다른글

관련글

티스토리툴바