sicherheitsvorkehrungen bei read-only service? (gelöst) (Perl/CGI)

[thread]17697[/thread]

sicherheitsvorkehrungen bei read-only service? [gelöst]

Tags: perl5 CGI Ähnliche Threads

Leser: 20

Articles: hide open all | hide show old branches

+8 replies
miwieg

2012-08-24 15:33

User since
2006-07-16
59 Artikel
BenutzerIn

Hallo,

Ich habe einen CGI-basierten Service mit Perl geschrieben, der unterschiedliche Anfragen auf strukturierte Daten ermöglicht.
Die strukturierten Daten liegen in einfachen txt-Dateien vor.
Der ganze Service ist für den Client read-only.

Mittlerweile läuft der Service wie vorgesehen.
Ich frage mich nur, ob man irgendwelche Sicherheitsvorkehrungen treffen sollte, wenn man eine solche Anwendung online stellt.
Besteht selbst bei read-only Anwendungen die Gefahr eines Server-"Angriffs"?
Wenn ja, was wären Standard-Vorkehrungen, die getroffen werden sollten.

Vielen Dank im Voraus.
- +4 replies
- Linuxer
  
  2012-08-24 15:46
  
  User since
  2006-01-27
  3870 Artikel
  HausmeisterIn
  
  Recht allgemein gehalten:
  
  - CGI-Skript im Tainted-Modus laufen lassen
  - User-Eingaben streng auf korrekte Daten kontrollieren
  - 3-Argument-Form des open verwenden
  - lexikalische Filehandles verwenden
  meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
  Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
  - +3 replies
  - miwieg
    
    2012-08-24 16:10
    
    User since
    2006-07-16
    59 Artikel
    BenutzerIn
    
    Danke für diese hilfreiche Antwort!
    
    Noch eine Anschlussfrage: was genau sollte man bei der User-Eingabe überprüfen?
    In meinem Service gibt es die Möglichkeit, per Textfeld etwas einzugeben.
    Wahrscheinlich sollte man die Zeichen überprüfen (nur gängige alphanumerische Zeichen) und die Länge beschränken?
    - pq
      
      2012-08-24 16:27
      
      User since
      2003-08-04
      12208 Artikel
      Admin1
      
      es ist egal, ob man per textfeld was eingeben kann oder nicht. jeder parameter, den du von aussen holst, ist manipulierbar.
      auf was du prüfst, hängt immer davon ab, was du anschliessend mit den daten anstellst. für datenbankabfragen solltest du z.b. platzhalter verwenden, für system-calls die form mit mehreren argumenten, und bei ausgabe als html einfach alles in html-entities umwandeln.
      pauschal zu sagen, du musst x und y rausfiltern, das geht so nicht.
      
      perldoc perlsec lesen
      http://bobby-tables.com/ für datenbankabfragen lesen
      Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
      lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
    - Linuxer
      
      2012-08-24 16:29
      
      User since
      2006-01-27
      3870 Artikel
      HausmeisterIn
      
      Naja,
      
      oft erwartet man der User-Eingabe ein bestimmtes Format (z.B. für eine IP-Adresse oder einen Dateinamen).
      
      Dann kann man eine Prüfung aufbauen, dass eben nur dieses Format erlaubt ist:
      - bei der IP-Adresse könnte man darauf prüfen, ob es nur Zahlen und Punkte sind (IPv4), oder man macht es noch genauer und prüft auch den Wertebereich (da wird der Regex etwas komplexer...)
      - bei Dateinamen könnte man darauf prüfen, dass der Benutzer wirklich nur einen Dateinamen eingibt; eine Eingabe von relativen oder absoluten Pfade könnte dann einen Fehler erzeugen, weil das nicht erlaubt ist.
      
      Auf was Du letzten Endes prüfst und was Du erlaubst oder verbietest, hängt von Deinem Anwendungsfall ab.
      Pauschal kann man das nicht einfach so beantworten...
      meine Beiträge: I.d.R. alle Angaben ohne Gewähr und auf Linux abgestimmt!
      Die Sprache heisst Perl, nicht PERL. - Bitte Crossposts als solche kenntlich machen!
- +2 replies
- topeg
  
  2012-08-24 17:28
  
  User since
  2006-07-10
  2611 Artikel
  BenutzerIn
  
  Du kennst deinen Code am besten.
  
  Stell dir vor du wolltest in deinen eigenen Service einbrechen. Versuch es mal wirklich. Überlege dir wo man Daten unerlaubt auslesen könnte und versuch diese Stelle zu erreichen.
  
  Stell dir vor irgendjemand gibt unsinnige Daten ein, werden solche Fehler ordentlich behandelt? Sende einfach mal unsinnige Eingaben und schau was passiert. Schreibe ein kleines Script das viele Anfragen sendet. Schaue ob dein Code irgendwo auseinander fällt.
  
  Mache viele Anfragen gültige Anfragen gleichzeitig und schau wie gut der Code damit klar kommt. Schau nach ob die DB im Hintergund über http zu erreichen ist. Schau nach ob noch irgendwo alte Tests sind die einen Einbruch erlauben könnten.
  
  Versuch wie ein Cracker zu denken.
  - miwieg
    
    2012-08-25 08:57
    
    User since
    2006-07-16
    59 Artikel
    BenutzerIn
    
    OK. Da habe ich ja einige gute Vorschläge bekommen. Vielen Dank!
- Gast g
  
  2012-08-25 09:15
  
  Liste auf http://perlpunks.de/paste/show/50387b0a.21c7.2b3?p...
  Last edited: 2012-08-25 09:45:23 +0200 (CEST)

View all threads created 2012-08-24 15:33.