1. Foren
  2. Kommentare
  3. Applikationen-Forum
  4. Alle Kommentare zum Artikel
  5. › Webbasierter FTP-Client

sicherheitsrisiko

Neue Foren im Freiraum! Raumfahrt und freie Software haben jetzt einen Platz, die Games tummeln sich jetzt alle in einem Forum.
  1. Thema

Neues Thema Ansicht wechseln


  1. sicherheitsrisiko

    Autor: nicoledos 10.03.08 - 09:26

    Früher als ich jung, naiv und unerfahren war hab ich solche dienste auch genutzt.

    Jetzt wird mir eher mulmig bei dem Gedanken, auf einer fremden Seite die Zugangsdaten meines Webservers einzugeben. Was ich dort machen kann, kann auch der Betreiber des Dienstes. Und selbst wenn der Betreiber fair und sicher agiert. Dann bleibt noch das Risiko, dass irgendwer die Seite Hijackt und so an die Daten kommt.

    Besser ist es einen Freien WebFTP-Client (mit integrierter Benutzerverwaltung) auf dem eigenen Server zu betreiben und ihn nochmal per http-acccess sperren, dasss kein fremder drauf kommt. Auch bieten fast alle Webhoster inzwischen eigene WebFTPs per ssl/https.

    Alles andere ist Russisch Roulett.

  2. Re: sicherheitsrisiko

    Autor: Necator 10.03.08 - 09:39

    Ich habe mir das Ding nicht angeguckt, aber wenn es ein Java-Applet ist, dann läuft das bei dir lokal, und nicht beim Webseitenbetreiber.
    Also werden deine daten wohlmöglich gar nicht zu diesem übermittelt.

  3. Re: sicherheitsrisiko

    Autor: marc2 10.03.08 - 09:47

    nicoledos schrieb:
    -------------------------------------------------------
    > Früher als ich jung, naiv und unerfahren war

    Zumindest bist Du noch nicht der Vollprofi, worauf Necator schon aufmerksam machte. ;-)

  4. Re: sicherheitsrisiko

    Autor: Süden 10.03.08 - 09:47

    Necator schrieb:
    -------------------------------------------------------
    > Ich habe mir das Ding nicht angeguckt, aber wenn
    > es ein Java-Applet ist, dann läuft das bei dir
    > lokal, und nicht beim Webseitenbetreiber.
    > Also werden deine daten wohlmöglich gar nicht zu
    > diesem übermittelt.
    >
    >

    ...aber man weiss nicht sicher, was im Hintergrund abläuft, oder?

  5. Re: sicherheitsrisiko

    Autor: LH_ 10.03.08 - 09:50

    Süden schrieb:
    -------------------------------------------------------
    > ...aber man weiss nicht sicher, was im Hintergrund
    > abläuft, oder?

    Wenn du die Verbindungsziele des Applets regelst (z.B. über eine Firewall) kannst du dir sicher sein.
    Zumal eine lokal installierte Software ebenfalls Backdoors und co. enthalten kann.

    Allerdings ist vorsicht gegenüber unbekannten Quellen immer eine gute Idee, ich will nicht sagen das du unvorsichtiger damit sein solltest, sondern eher bei lokaler Software ebenfalls kritisch sein solltest :)

  6. Re: sicherheitsrisiko

    Autor: GrinderFX 10.03.08 - 10:01

    marc2 schrieb:
    -------------------------------------------------------
    > nicoledos schrieb:
    > --------------------------------------------------
    > -----
    > > Früher als ich jung, naiv und unerfahren war
    >
    > Zumindest bist Du noch nicht der Vollprofi, worauf
    > Necator schon aufmerksam machte. ;-)

    Lol,treffer versenkt.

  7. Re: sicherheitsrisiko

    Autor: GG 10.03.08 - 10:14


    > ...aber man weiss nicht sicher, was im Hintergrund
    > abläuft, oder?
    >

    weisst Du das denn sonst?

  8. Re: sicherheitsrisiko

    Autor: nicoledos 10.03.08 - 10:29

    marc2 schrieb:
    -------------------------------------------------------
    > nicoledos schrieb:
    > --------------------------------------------------
    > -----
    > > Früher als ich jung, naiv und unerfahren war
    >
    > Zumindest bist Du noch nicht der Vollprofi, worauf
    > Necator schon aufmerksam machte. ;-)

    Ab wann ist man denn ein Vollprofi?
    Auch ein Java-Applett von einer externen Seite kann ein Sicherheitsrisiko darstellen.

    Sicher gibt es Scanner, Firewalls, ... . Wie gut die Funktionieren weiss keiner wirklich und Warnungen werden von 95% der User sowieso nicht Verstanden und weg geklickt. Was glaubst du wieviel User bei mir meckern, dass sich Kaspersky dauernd aktuallisiert. Benutzeraussage "Das war mit Norton aber schöner, der hat sich nicht so oft gemeldet."

    Genau aus dem Grund, sind derartige Externe Dienste ein Sicherheitsrisiko. Zumal niemand Einfluss auf den Anbieter selbst hat, was der dort macht. Das sind Dienste aus der Internetsteinzeit. Heute braucht man diese nicht mehr. Warum noch einen WebFTP-Client verwenden, wenn der Hoster selbst einen bietet.

  9. Re: sicherheitsrisiko

    Autor: javascriptniete 10.03.08 - 11:29

    Mitnichten. Wenn es ein Java-Applet ist, läuft es zwar lokal, aber es darf sich nur zu dem Rechner verbinden, von dem es stammt. Mit anderen Worten: alle Deine Daten landen erstmal bei anyclient.com! Dort wird die FTP-Verbindung zu dem angegebenen FTP-Server aufgebaut, und jeglicher FTP-Transfer wird zwischen anyclient.com und dem FTP-Server abgewickelt. Wenn Du Glück hast, bekommst Du die FTP-Daten schließlich über das Applet auch auf Deinen Rechner, und wenn Du noch mehr Glück hast, speichert anyclient.com diese Daten nicht...


    Necator schrieb:
    -------------------------------------------------------
    > Ich habe mir das Ding nicht angeguckt, aber wenn
    > es ein Java-Applet ist, dann läuft das bei dir
    > lokal, und nicht beim Webseitenbetreiber.
    > Also werden deine daten wohlmöglich gar nicht zu
    > diesem übermittelt.

  10. Re: sicherheitsrisiko

    Autor: rr 10.03.08 - 12:18

    Selten so einen Schwachsinn gelesen. Natürlich darf ein Javaapplet eine direktverbindung zu einem anderen host aufnehmen. Dafür wird das Applet ordentlich signiert. Mit der Signatur kann man außerdem die zusätzlich benötigen Rechte auf dem Client hinterlegen. Der SecurityManager kümmert sich dann drum den Benutzer zu fragen, ob das Applet das darf und wenn der nö sagt, DANN kann die Anwendung keinen Stream woanders hin aufmachen. Im übrigen kann die Anwendung ebensowenig einen direkten Stream zu dem Host aufbauen, von dem das Applet kommt. Man kann allenfalls jars nachladen, aber die müssen, wenn passend signiert, auch nicht unbedingt auf einem einzigen host liegen.

    Nächste ma einfach Klappe halten, wenn man keine Ahnung hat. Danke.


    javascriptniete schrieb:
    -------------------------------------------------------
    > Mitnichten. Wenn es ein Java-Applet ist, läuft es
    > zwar lokal, aber es darf sich nur zu dem Rechner
    > verbinden, von dem es stammt. Mit anderen Worten:
    > alle Deine Daten landen erstmal bei anyclient.com!
    > Dort wird die FTP-Verbindung zu dem angegebenen
    > FTP-Server aufgebaut, und jeglicher FTP-Transfer
    > wird zwischen anyclient.com und dem FTP-Server
    > abgewickelt. Wenn Du Glück hast, bekommst Du die
    > FTP-Daten schließlich über das Applet auch auf
    > Deinen Rechner, und wenn Du noch mehr Glück hast,
    > speichert anyclient.com diese Daten nicht...
    >
    > Necator schrieb:
    > --------------------------------------------------
    > -----
    > > Ich habe mir das Ding nicht angeguckt, aber
    > wenn
    > es ein Java-Applet ist, dann läuft das
    > bei dir
    > lokal, und nicht beim
    > Webseitenbetreiber.
    > Also werden deine daten
    > wohlmöglich gar nicht zu
    > diesem übermittelt.
    >
    >


  11. Re: sicherheitsrisiko

    Autor: rr 10.03.08 - 12:22

    Das reele Risiko, was bei einem Java-Applet besteht, währe Code der gezielt Daten irgendwohin versendet. Exakt das Gleiche Risiko besteht aber auch bei jeder anderen Client-Anwendung.

    nicoledos schrieb:
    -------------------------------------------------------
    > Früher als ich jung, naiv und unerfahren war hab
    > ich solche dienste auch genutzt.
    >
    > Jetzt wird mir eher mulmig bei dem Gedanken, auf
    > einer fremden Seite die Zugangsdaten meines
    > Webservers einzugeben. Was ich dort machen kann,
    > kann auch der Betreiber des Dienstes. Und selbst
    > wenn der Betreiber fair und sicher agiert. Dann
    > bleibt noch das Risiko, dass irgendwer die Seite
    > Hijackt und so an die Daten kommt.
    >
    > Besser ist es einen Freien WebFTP-Client (mit
    > integrierter Benutzerverwaltung) auf dem eigenen
    > Server zu betreiben und ihn nochmal per
    > http-acccess sperren, dasss kein fremder drauf
    > kommt. Auch bieten fast alle Webhoster inzwischen
    > eigene WebFTPs per ssl/https.
    >
    > Alles andere ist Russisch Roulett.


  12. Re: sicherheitsrisiko

    Autor: birdman 10.03.08 - 13:28

    > Ab wann ist man denn ein Vollprofi?
    du bist schonmal keiner.

    > Auch ein Java-Applett von einer externen Seite
    > kann ein Sicherheitsrisiko darstellen.
    JEDES programm kann ein sicherheitsrisiko darstellen, wenn du es nicht selbst im quellcode gegenprüfst. oder willst du mir erzählen, du hast dich mit microsoft zusammengetan und ein exklusives source-auditing durchgeführt, um dich davon zu überzeugen, dass windows auch wirklich keine daten auf hypotetische NSA-backbones überträgt...?

    > Sicher gibt es Scanner, Firewalls, ... . Wie gut
    > die Funktionieren weiss keiner wirklich und
    > Warnungen werden von 95% der User sowieso nicht
    > Verstanden und weg geklickt. Was glaubst du
    > wieviel User bei mir meckern, dass sich Kaspersky
    > dauernd aktuallisiert. Benutzeraussage "Das war
    > mit Norton aber schöner, der hat sich nicht so oft
    > gemeldet."

    ich kenne ebenfalls viele user dieses typus. aber mir fällt kein einziger ein, der die kompetenz hätte, mit einem ftp-server umzugehen, geschweigedenn mit web2ftp. aber unabhängig davon: was zur hölle haben norton-fanboys mit web2ftp zu tun? macht es für die sicherheit der applikation einen unterschied, ob die zugangsdaten von einem DAU oder von einem IT-professor eingegeben werden? falls ja, siehe 1.

    > Genau aus dem Grund, sind derartige Externe
    > Dienste ein Sicherheitsrisiko. Zumal niemand
    > Einfluss auf den Anbieter selbst hat, was der dort
    > macht. Das sind Dienste aus der Internetsteinzeit.
    > Heute braucht man diese nicht mehr. Warum noch
    > einen WebFTP-Client verwenden, wenn der Hoster
    > selbst einen bietet.

    internetsteinzeit? hast du überhaupt den hauch einer ahnung, wie es bis zum heutigen "internet" gekommen ist? webftp-clients hatten damit jedenfalls exakt garnichts zu tun. was ist, wenn der hoster keinen webftp anbietet? oder die applikation nicht stabil läuft? oder schlichtweg unbedienbar ist? oder die frontend des hosters wegen wartungsarbeiten nicht funktioniert? oder einfach nur gesperrt ist, weil man über einen hotspot im netz ist? oder......

  13. Re: sicherheitsrisiko

    Autor: javascriptniete 10.03.08 - 14:02

    Gemach, Gemach.

    OK, das Applet ist signiert, hätte ich mir ja vorher ansehen können. Allerdings darf es schlichtweg *alles*, d.h. es ist genauso "sicher" wie ein signiertes ActiveX :O Der SecurityManager fragt infolgedessen natürlich auch nur, ob das Applet jetzt ohne Einschränkungen laufen darf - alles oder nix, Glückwunsch!



    rr schrieb:
    -------------------------------------------------------
    > Selten so einen Schwachsinn gelesen. Natürlich
    > darf ein Javaapplet eine direktverbindung zu einem
    > anderen host aufnehmen. Dafür wird das Applet
    > ordentlich signiert. Mit der Signatur kann man
    > außerdem die zusätzlich benötigen Rechte auf dem
    > Client hinterlegen. Der SecurityManager kümmert
    > sich dann drum den Benutzer zu fragen, ob das
    > Applet das darf und wenn der nö sagt, DANN kann
    > die Anwendung keinen Stream woanders hin
    > aufmachen. Im übrigen kann die Anwendung
    > ebensowenig einen direkten Stream zu dem Host
    > aufbauen, von dem das Applet kommt. Man kann
    > allenfalls jars nachladen, aber die müssen, wenn
    > passend signiert, auch nicht unbedingt auf einem
    > einzigen host liegen.
    >
    > Nächste ma einfach Klappe halten, wenn man keine
    > Ahnung hat. Danke.
    >
    > javascriptniete schrieb:
    > --------------------------------------------------
    > -----
    > > Mitnichten. Wenn es ein Java-Applet ist,
    > läuft es
    > zwar lokal, aber es darf sich nur zu
    > dem Rechner
    > verbinden, von dem es stammt. Mit
    > anderen Worten:
    > alle Deine Daten landen
    > erstmal bei anyclient.com!
    > Dort wird die
    > FTP-Verbindung zu dem angegebenen
    > FTP-Server
    > aufgebaut, und jeglicher FTP-Transfer
    > wird
    > zwischen anyclient.com und dem FTP-Server
    >
    > abgewickelt. Wenn Du Glück hast, bekommst Du
    > die
    > FTP-Daten schließlich über das Applet
    > auch auf
    > Deinen Rechner, und wenn Du noch
    > mehr Glück hast,
    > speichert anyclient.com
    > diese Daten nicht...

  14. Re: sicherheitsrisiko

    Autor: rr 10.03.08 - 14:23

    Das ist wohl wahr, ein wenig differenzierter hätte man das vielleicht konfigurieren können ;-)

    javascriptniete schrieb:
    -------------------------------------------------------
    > Gemach, Gemach.
    >
    > OK, das Applet ist signiert, hätte ich mir ja
    > vorher ansehen können. Allerdings darf es
    > schlichtweg *alles*, d.h. es ist genauso "sicher"
    > wie ein signiertes ActiveX :O Der SecurityManager
    > fragt infolgedessen natürlich auch nur, ob das
    > Applet jetzt ohne Einschränkungen laufen darf -
    > alles oder nix, Glückwunsch!
    >
    > rr schrieb:
    > --------------------------------------------------
    > -----
    > > Selten so einen Schwachsinn gelesen.
    > Natürlich
    > darf ein Javaapplet eine
    > direktverbindung zu einem
    > anderen host
    > aufnehmen. Dafür wird das Applet
    > ordentlich
    > signiert. Mit der Signatur kann man
    > außerdem
    > die zusätzlich benötigen Rechte auf dem
    >
    > Client hinterlegen. Der SecurityManager
    > kümmert
    > sich dann drum den Benutzer zu
    > fragen, ob das
    > Applet das darf und wenn der
    > nö sagt, DANN kann
    > die Anwendung keinen
    > Stream woanders hin
    > aufmachen. Im übrigen
    > kann die Anwendung
    > ebensowenig einen direkten
    > Stream zu dem Host
    > aufbauen, von dem das
    > Applet kommt. Man kann
    > allenfalls jars
    > nachladen, aber die müssen, wenn
    > passend
    > signiert, auch nicht unbedingt auf einem
    >
    > einzigen host liegen.
    >
    > Nächste ma
    > einfach Klappe halten, wenn man keine
    > Ahnung
    > hat. Danke.
    >
    > javascriptniete
    > schrieb:
    >
    > --------------------------------------------------
    >
    > -----
    > > Mitnichten. Wenn es ein
    > Java-Applet ist,
    > läuft es
    > zwar lokal,
    > aber es darf sich nur zu
    > dem Rechner
    >
    > verbinden, von dem es stammt. Mit
    > anderen
    > Worten:
    > alle Deine Daten landen
    > erstmal
    > bei anyclient.com!
    > Dort wird die
    >
    > FTP-Verbindung zu dem angegebenen
    >
    > FTP-Server
    > aufgebaut, und jeglicher
    > FTP-Transfer
    > wird
    > zwischen anyclient.com
    > und dem FTP-Server
    >
    > abgewickelt. Wenn Du
    > Glück hast, bekommst Du
    > die
    > FTP-Daten
    > schließlich über das Applet
    > auch auf
    >
    > Deinen Rechner, und wenn Du noch
    > mehr Glück
    > hast,
    > speichert anyclient.com
    > diese
    > Daten nicht...
    >


  1. Thema

Neues Thema Ansicht wechseln


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. Business Performance Data Specialist (m/w/d)
    AGCO GmbH, Marktoberdorf
  2. Teamleiter (m/w/d) Informationsmanagement SAP BW & SAP Basis
    Radeberger Gruppe KG, Frankfurt am Main
  3. Softwareentwicklerin, Physikerin oder Ingenieurin (m/w/d)
    Helmholtz-Zentrum hereon GmbH, Geesthacht
  4. Fulfillment Experte / Projektleiter Operations Prozesse/E-Commerce Warehouse (mobiles Arbeiten) ... (m/w/d)
    DPD Deutschland GmbH, Raum Frankfurt am Main, München, Dortmund (Home-Office)

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 499,99€
  2. 499,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de