1. Foren
  2. Kommentare
  3. Software-Entwicklung-Forum
  4. Alle Kommentare zum Artikel
  5. › Native Client von…

nicht sicher umsetzbar

  1. Thema

Neues Thema


  1. nicht sicher umsetzbar

    Autor: typhoon 09.12.08 - 13:00

    der sinn und zweck von client-server architekturen ist doch die tatsache, daß der client nur möglichst klein und dumm ist. bei webapplikationen eben für die darstellung von websiten. die ganze logik die dahinter steckt wird vom server übernommen. damit stellt google das ganze system auf den kopf. zudem halte ich es nicht für umsetztbar, daß das ganze aus sicht der serverbetreiber sicher sein kann. sobald man an den code rankommt. in diesem fall wird der code an den client übertragen, der dann diesen code ausführen soll. und schon hat man einblick in die gesamte logik die auf dem server läuft und damit ist alles viel leichter angreifbar. sobald man an einen rechner physikalisch rankommt ist er knackbar. wenn ich alles dann auch noch freiwillig auf fremde rechner transferiere die ich nicht kenne ...

  2. Re: nicht sicher umsetzbar

    Autor: nixblick... 09.12.08 - 13:20

    Es geht hier um die Sicherheit des NATIVEN-CODES. Das hat mal absolut gar nichts mit der Client-Server Architektur zu tun. Aus Sicht des Servers ist das ganze übrigens absolut Sicher, nur der Client wird einem Risiko ausgesetzt.

    1. [x] Gelesen
    2. [ ] Verstanden
    3. [x] Gepostet

    Bitte Schritt 2 nicht vergessen.

  3. Re: nicht sicher umsetzbar

    Autor: typhoon 09.12.08 - 20:40

    solltest vielleicht nochmal drüberlesen. bei dir triftt wohl nur punkt 3 zu.

  4. Re: nicht sicher umsetzbar

    Autor: na_genau 09.12.08 - 23:56

    Würde ich Dir ebenfalls raten. Es geht hier rein um die Sicherheit des Clients. Aber das ist ja ein Problem, dem man sich schon länger gegenüber sieht. Warum glaubst Du, dass es Laufzeitumgebungen wie Java oder .Net gibt? ^^

    Nur zur Rechenzeitvernichtung? Dir dürfte der Sinn von Code based Security und all den weiteren Sicherheitsmerkmalen moderner Laufzeitumgebungen nicht so ganz geläufig sein. Es geht hier darum, dass es bei nativem Code viel schwieriger ist, die Funktion zu überprüfen und damit sicherzustellen, dass der Code weder beabsichtigt noch unbeabsichtigt die Clientsicherheit gefährdet. Ein Beispiel (kann man bringen, weil sie eh schon durch das NX-Flag entschärft wurden) sind Buffer-Overflow-Attacken (falls Du weisst, wie sie funktionieren). In Java oder .Net waren die außer bei Bugs in den RTEs nie ein Thema, bei C/C++ musstest Du Dich bei jeder einzelnen Anwendung selbst drum kümmern und da ist schnell mal was vergessen ;-)

    Auf der Serverseite kannst Du genauso gut ein Webservice schreiben, mit dem der Client kommunizieren kann und das ist ja nicht weniger sicher als eine herkömmliche Webschnittstelle (wiel sie zumeist sogar die gleiche Basis haben).

  5. Re: nicht sicher umsetzbar

    Autor: loldog 10.12.08 - 08:32

    >der sinn und zweck von client-server architekturen ist doch die >tatsache, daß der client nur möglichst klein und dumm ist.
    So ein Quatsch. Client-Server kann alles Mögliche sein. Das Clientprogramm könnte auch weitaus komplexer und umfangreicher als das Serverprogramm sein.
    >bei webapplikationen eben für die darstellung von websiten. die ganze >logik die dahinter steckt wird vom server übernommen.
    Genau hiervon bewegt sich der Trend aber gerade weg. AJAX und Web 2.0 und so. Hast du da was verpasst?
    >damit stellt google das ganze system auf den kopf.
    kein Kommentar...
    >zudem halte ich es nicht für umsetztbar, daß das ganze aus sicht der >serverbetreiber sicher sein kann. sobald man an den code rankommt. > in diesem fall wird der code an den client übertragen, der dann diesen >code ausführen soll. und schon hat man einblick in die gesamte logik >die auf dem server läuft und damit ist alles viel leichter angreifbar.
    Der Client bekommt doch den Client Code, nicht den Servercode. Und selbst wenn der Angreifer den Quelltext für den Server hat, heißt das nicht dass er sich ohne weiteres einen Angriff daraus stricken kann. Der Apache-Webserver (darauf laufen die Hälfte aller Webserver) Quelltext ist z.B. öffentlich zugänglich.
    > sobald man an einen rechner physikalisch rankommt ist er knackbar.
    "Physikalisch" an einen rechner rankommen bedeutet, ihn tatsächlich anfassen zu können, um ihn z.B. mit einem Hammer kaputt zu schlagen.
    Ja, insofern kannst du ihn knacken. Du könntest auch die Festplatte rausbauen um an die (nichtverschlüsselten) Daten ranzukommen. Dazu müsstest du lediglich, ganz physikalisch, in dem Betrieb einbrechen...

    Tut mir leid, aber du hast nur eine vage Ahnung von dem was du da schreibst...

  6. Re: nicht sicher umsetzbar

    Autor: loldog 10.12.08 - 08:32

    >der sinn und zweck von client-server architekturen ist doch die >tatsache, daß der client nur möglichst klein und dumm ist.
    So ein Quatsch. Client-Server kann alles Mögliche sein. Das Clientprogramm könnte auch weitaus komplexer und umfangreicher als das Serverprogramm sein.
    >bei webapplikationen eben für die darstellung von websiten. die ganze >logik die dahinter steckt wird vom server übernommen.
    Genau hiervon bewegt sich der Trend aber gerade weg. AJAX und Web 2.0 und so. Hast du da was verpasst?
    >damit stellt google das ganze system auf den kopf.
    kein Kommentar...
    >zudem halte ich es nicht für umsetztbar, daß das ganze aus sicht der >serverbetreiber sicher sein kann. sobald man an den code rankommt. > in diesem fall wird der code an den client übertragen, der dann diesen >code ausführen soll. und schon hat man einblick in die gesamte logik >die auf dem server läuft und damit ist alles viel leichter angreifbar.
    Der Client bekommt doch den Client Code, nicht den Servercode. Und selbst wenn der Angreifer den Quelltext für den Server hat, heißt das nicht dass er sich ohne weiteres einen Angriff daraus stricken kann. Der Apache-Webserver (darauf laufen die Hälfte aller Webserver) Quelltext ist z.B. öffentlich zugänglich.
    > sobald man an einen rechner physikalisch rankommt ist er knackbar.
    "Physikalisch" an einen rechner rankommen bedeutet, ihn tatsächlich anfassen zu können, um ihn z.B. mit einem Hammer kaputt zu schlagen.
    Ja, insofern kannst du ihn knacken. Du könntest auch die Festplatte rausbauen um an die (nichtverschlüsselten) Daten ranzukommen. Dazu müsstest du lediglich, ganz physikalisch, in dem Betrieb einbrechen...

    Tut mir leid, aber du hast nur eine vage Ahnung von dem was du da schreibst...

  1. Thema

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. SAP Integration Architect (m/w/d)
    sonnen GmbH, Berlin, Wildpoldsried
  2. IT Operations Manager (m/w/d)
    Masterflex SE, Gelsenkirchen
  3. Spezialist*in (w/m/d) im Messwesen
    Bundesnetzagentur, Mainz
  4. IT-Administrator*in (m/w/d)
    Universitätsmedizin der Johannes Gutenberg-Universität Mainz, Mainz

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de