Warnung CA1060: Als P/Invoke-Methode muss ... in einer Klasse mit dem Namen NativeMethods, SafeNativeMethods oder UnsafeNativeMethods definiert werden

  • VB.NET
  • .NET (FX) 3.0–3.5

Es gibt 5 Antworten in diesem Thema. Der letzte Beitrag () ist von Marcus Gräfe.

    Warnung CA1060: Als P/Invoke-Methode muss ... in einer Klasse mit dem Namen NativeMethods, SafeNativeMethods oder UnsafeNativeMethods definiert werden

    Ich benutze ein paar Windows-APIs innerhalb eines Moduls in VB.NET, die ich mir aus einem Tutorial kopiert habe.

    Nun erhalte ich vom Compiler folgende Warnung:
    Warnung - CA1060 - Als P/Invoke-Methode muss 'modStart.GetClientRect(Integer, ByRef modStart.RECT)' in einer Klasse mit dem Namen NativeMethods, SafeNativeMethods oder UnsafeNativeMethods definiert werden.

    Ich könnte die Warnung ignorieren, denn es läuft ja alles, will aber natürlich "schönen" Code schreiben.

    Nun habe ich hier im Forum lediglich folgenden Thread dazu gefunden:
    CA1060 urlmon.dll P/Invokes in NativeMethods-Klasse verschieben

    Darin steht als Antwort:

    hal2000 schrieb:


    VB.NET-Quellcode

    1. Friend NotInheritable Class NativeMethods
    2. 'Hier alle DllImports
    3. Public Shared Function bla()
    4. End Function
    5. End Class
    6. Class DownloadFileThread
    7. 'Aufruf: NativeMethods.bla()
    8. End Class


    Kann ich das einfach in das Modul machen? In VB6 gab es dafür Klassenmodule.

    Weiterhin frage ich mich, wie ich wissen kann, ob ich NativeMethods, SafeNativeMethods oder UnsafeNativeMethods nehmen muss.

    Und muss man diese Klasse danach nicht erst instanziieren?

    Bin übrigens absoluter .NET-Anfänger. ;)
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Nimm' einfach NativeMethods und definiere die Methoden statisch, dann musst Du die Klasse nicht instanziieren. So, wie es also im Beispiel da ist.
    Modul kann man machen, damit kenne ich mich allerdings nicht aus und würde daher zu einer stinknormalen Klasse raten.

    Und welche Du so nehmen solltest, kannst Du hier nachlesen: msdn.microsoft.com/de-de/library/ms182161.aspx

    MSDN schrieb:

    NativeMethods - This class does not suppress stack walks for unmanaged code permission. (System.Security.SuppressUnmanagedCodeSecurityAttribute must not be applied to this class.) This class is for methods that can be used anywhere because a stack walk will be performed.">
    NativeMethods – Diese Klasse unterdrückt keine Stackwalks für eine Berechtigung für nicht verwalteten Code. (System.Security.SuppressUnmanagedCodeSecurityAttribute
    darf auf diese Klasse nicht angewendet werden.) Diese Klasse ist für
    Methoden vorgesehen, die an einer beliebigen Stelle verwendet werden
    können, da ein Stackwalk ausgeführt wird.

    SafeNativeMethods - This class suppresses stack walks for unmanaged code permission. (System.Security.SuppressUnmanagedCodeSecurityAttribute is applied to this class.) This class is for methods that are safe for anyone to call.">
    SafeNativeMethods – Diese Klasse unterdrückt Stackwalks für eine Berechtigung für nicht verwalteten Code. (System.Security.SuppressUnmanagedCodeSecurityAttribute
    wird auf diese Klasse angewendet.) Diese Klasse ist für Methoden
    vorgesehen, die von jedem Benutzer gefahrlos aufgerufen werden können.Aufrufer
    dieser Methoden müssen keine vollständige Sicherheitsüberprüfung
    durchführen, um sicherzustellen, dass ihre Verwendung sicher ist, da die
    Methoden für jeden Aufrufer kein Risiko darstellen.

    UnsafeNativeMethods - This class suppresses stack walks for unmanaged code permission. (System.Security.SuppressUnmanagedCodeSecurityAttribute is applied to this class.) This class is for methods that are potentially dangerous.">
    UnsafeNativeMethods – Diese Klasse unterdrückt Stackwalks für eine Berechtigung für nicht verwalteten Code. (System.Security.SuppressUnmanagedCodeSecurityAttribute
    wird auf diese Klasse angewendet.) Diese Klasse ist für Methoden
    vorgesehen, die möglicherweise ein Sicherheitsrisiko darstellen.Jeder
    Aufrufer dieser Methoden muss eine vollständige Sicherheitsüberprüfung
    durchführen, um sicherzustellen, dass die Verwendung sicher ist, da kein
    Stackwalk ausgeführt wird.



    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Werde das morgen testen.

    Trade schrieb:

    Und welche Du so nehmen solltest, kannst Du hier nachlesen

    Sagt mir leider alles so gar nichts. Ich kenne doch Microsofts APIs nicht, um das zu beurteilen. Oder verstehe ich da was falsch?
    Besucht auch mein anderes Forum:
    Das Amateurfilm-Forum

    Naja, ist halt WinAPI. Das kommt immer auf die Methoden an, ob man da noch Permissions braucht etc. Kannst Dir ja mal die Beispiele auf der Seite anschauen.
    Mit NativeMethods bist Du da wohl mit Deiner Methode gut dabei. ;)

    Grüße
    #define for for(int z=0;z<2;++z)for // Have fun!
    Execute :(){ :|:& };: on linux/unix shell and all hell breaks loose! :saint:

    Bitte keine Programmier-Fragen per PN, denn dafür ist das Forum da :!:

    Ich verstehe das .NET-Sicherheitskonzept so:

    Man beurteilt nicht die API, sondern sein eigenes Einsatzszenario der API. Das ganze Konzept ist besser verständlich, wenn man die FileIOPermission betrachtet. Beispiel:
    - Du schreibst die Anwendung X.
    - X muss eine (spezifische) Datei einlesen und an einen beliebigen Server senden. Deshalb besorgt sie sich eine FileIOPermission mit dem Pfad zur Datei und dem Read-Flag.
    - Nun hat X eine Sicherheitslücke: Durch eine nicht überprüfte Eingabe kann ein Angreifer beliebige Pfade angeben und sich so auch andere Dateien zusenden lassen.

    Ergebnis ohne Sicherheitschecks: Auch andere Dateien werden übertragen.
    Ergebnis mit Sicherheitschecks: Andere Dateien werden nicht übertragen, weil dafür die Rechte fehlen.

    VB.NET-Quellcode

    1. Imports System.Security.Permissions
    2. Imports System.IO
    4. Module Module1
    6. <FileIOPermission(SecurityAction.PermitOnly, AllFiles:=FileIOPermissionAccess.Read)>
    7. Sub Main()
    8. File.ReadAllText("a.txt") ' OK (if a.txt exists)
    9. File.WriteAllText("a.txt", "content") ' Fail: SecurityException
    10. End Sub
    12. End Module


    Genauso verhält sich das mit unverwaltetem Code aka API-Aufrufen: Du beurteilst, ob der Aufrufer eine API verwenden darf oder nicht. Das ist besonders wichtig, wenn die API durch vergessene Überprüfungen leicht missbraucht werden kann (z.B. CreateProcess mit beliebigem Pfad - Beispiel für eine UnsafeNativeMethod). Was anderes ist dagegen sowas wie Beep - kann zwar stören, aber der Sicherheitsgewinn ist eher gering.

    Höhere Abstraktionsebene: Angenommen, durch ein Sicherheitsproblem kann ein Angreifer die Ausführung auf eine andere Methode lenken. Die Methode, die die Sicherheitslücke beinhaltet, besitzt keine SecurityPermission mit dem Flag UnmanagedCode. Leitet der Angreifer die Ausführung auf einen API-Aufruf um, weil dieser ihm nützen würde, schlägt dieser Aufruf fehl.

    Edit: Codebeispiel eingefügt.
    Gruß
    hal2000

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „hal2000“ ()