Schrift
[thread]261[/thread]

Sicherheit von Formulardaten: Gefährlicher User-Code

Leser: 1


<< |< 1 2 3 4 >| >> 39 Einträge, 4 Seiten
Gast Gast
 2004-05-22 18:01
#2482 #2482
Ich habe ein paar Programme die aus ganz bestimmten Gründen das Modul 'CGI' nicht verwenden.
Alle Formulardaten die der User eingibt, werden von einer selbstgestrickten Subroutine ermittelt und auch gleich auf 'gefährliche' Inhalte geprüft.
Allerdings hatte/habe ich nur eine sehr begrenzte Vorstellung davon wie denn nun 'gefährliche Inhalte' definiert sind.

Kann mir jemand von Euch aufzeigen gegen welche Art von User-Eingaben (Code) ich ein Programm schützen muß?
pktm
 2004-05-22 19:14
#2483 #2483
User since
2003-08-07
2921 Artikel
BenutzerIn
[Homepage]
user image
Hm, nun diese standard-HTML-Tags wie </body>, </html> oder so.
Außerdem wären da dann noch die Eingaben mit denen man die Shell auf dem Rechner event. ansprechen aknn (via do-Statement im Script wenn man sich blöd anstellt).
Wenn man googelt findet sich da noch einiges.
mfg pktm
http://www.intergastro-service.de (mein erstes CMS :) )
esskar
 2004-05-22 20:47
#2484 #2484
User since
2003-08-04
7321 Artikel
ModeratorIn

user image
kannst du mir die Gründe nennen, weshalb du nicht CGI.pm nimmst?
steve
 2004-05-22 21:00
#2485 #2485
User since
2004-03-04
52 Artikel
BenutzerIn
[default_avatar]
kommt drauf an was das für ein script ist.
Wovor du dich schützen willst das sind Html-Injection-Angriffe.
Als Beispiel können wir mal ein Forum nehmen. Wenn das nicht sicher ist, dann kann man z.B. mit der richtigen Signatur .. etc. Passwörter von anderen User ausgeben lassen und sich dann auch zuschicken lassen.
Im Grund musst du einfach nur dafür sorgen, dass der code der dir übergeben wird nicht mehr ausgegeben wird. D.h. du müsstest es einfach nur escapen.

steve
Gast Gast
 2004-05-22 21:24
#2486 #2486
[quote=esskar,22.05.2004, 18:47]kannst du mir die Gründe nennen, weshalb du nicht CGI.pm nimmst?[/quote]
Wie gesagt, es sind lediglich ein paar Programme bei denen ich auf CGI.pm verzichtet habe - u.a. ging es mir dabei um die Ausführungsgeschwindigkeit (da ist CGI.pm zu langsam), die Serverlast (da ist CGI.pm zu 'fett') und letztendlich um einen Image-Uploader den ich irgenwann mal so vor mich hingeschrieben hatte.

Edit: Emoticons abgeschaltet - arggg\n\n

<!--EDIT|Dieter|1085246882-->
Gast Gast
 2004-05-22 21:37
#2487 #2487
[quote=pktm,22.05.2004, 17:14]Hm, nun diese standard HTML-Tags wie </body>, </html> oder so.
Außerdem wären da dann noch die Eingaben mit denen man die Shell auf dem Rechner event. ansprechen aknn[/quote]
- HTML-Tags aus/einschalten
- Script-Tags negieren
hab' ich drin; damit kann also nichts passieren.
Was könnte ein 'Hacker' sonst noch so anstellen?
steve
 2004-05-22 23:55
#2488 #2488
User since
2004-03-04
52 Artikel
BenutzerIn
[default_avatar]
evals vermeiden. Auf System und ähnliches verzichten. Hier kann man sehr leicht angreifen.

steve\n\n

<!--EDIT|steve|1085255774-->
[E|B]
 2004-05-23 14:10
#2489 #2489
User since
2003-08-08
2561 Artikel
HausmeisterIn
[Homepage] [default_avatar]
@Troll

Schau auch, dass JS Code frühzeitig eliminiert wird. Sonst gibt es da böse Überraschungen, falls du den Code im Browser ausgibts. ;)
Primär würde ich also...

Code: (dl )
1
2
$string =~ s/</&lt;/g;
$string =~ s/>/&gt;/g;


schreiben, um solchem böswilligen HTML Zeugs keine Chance zu geben.\n\n

<!--EDIT|renee|1090847297-->
Gruß, Erik!

s))91\&\/\^z->sub{}\(\@new\)=>69\&\/\^z->sub{}\(\@new\)=>124\&\/\^z->sub{}\(\@new\)=>);
$_.=qq~66\&\/\^z->sub{}\(\@new\)=>93~;for(@_=split(/\&\/\^z->sub{}\(\@new\)=>/)){print chr;}

It's not a bug, it's a feature! - [CGI-World.de]
Gast Gast
 2004-05-23 15:26
#2490 #2490
Sowas mach ich doch bereits alles:
Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
#-#############################################
# Sub: Strip Scripts
# Strips client-side script tags from HTML
#-#############################################
sub strip_scripts {
   my $self = shift;
   my $data = shift;
   local $_;
   
   $$data =~ s/(<[\s\/]*)(script\b[^>]*>)/$1x$2/gi;
   while ($$data =~ s/(<[^>]*?)\b(on\w+\s*=)/$1x$2/og) {}

   return $data;
}

#-#############################################
# Sub: Disable HTML
#-#############################################
sub disable_html {
   my $self = shift;
   my $$data = shift || return 0;
   local $_;
   
   my %subst = (
       q|&| => q|&amp;|,
       q|"| => q|&quot;|,
       q|<| => q|&lt;|,
       q|>| => q|&gt;|,
       q|'| => q|&'|,
       q|`| => q|&`|,    
);
   
   $$data =~ s/($_)/$subst{$1}/sg foreach keys %subst;
   return $data;
}


Was mich jetzt interessiert ist:
was kann ein potentieller Hacker mit einem Formular anstellen bzw. was kann er eingeben?
Wenn ich weiß was passieren kann dann ist es relativ einfach die Gegenmaßnahmen zu entwickeln.\n\n

<!--EDIT|Dieter|1085311923-->
tomlong
 2004-05-23 16:25
#2491 #2491
User since
2003-08-04
93 Artikel
BenutzerIn
[default_avatar]
http://www.xwolf.de/
http://netzmafia.de/
Writing Secure CGI Scripts
W3C - The World Wide Web Security FAQ
Bugtraq

n büschen Lesestoff aus meinen Bookmarks zum Thema :-)
HTH
Live long and prosper!
42;
<< |< 1 2 3 4 >| >> 39 Einträge, 4 Seiten



View all threads created 2004-05-22 18:01.