Vanliga säkerhetshål och lösningar

PHPportalen Forum Index » PHP
Lägg ett bokmärke på hela tråden
Skapa nytt inlägg   Svara på inlägget Gå till sida Föregående  1, 2, 3 ... , 9, 10, 11  Nästa
Visa föregående ämne :: Visa nästa ämne  
Startad av: Meddelande
bds



Medlem i: 4216 dagar
Från: Vallentuna
Status: Offline



#646327
Inlägg Skrivet: 2009-07-11 15:17      Ämne: Citera

pengi skrev:
bds skrev:
Måste bara lägga till en notis, de är att du säger att
"(lägg märke till att nl2br körs efteråt, annars kommer alla <br> synas på sidan som text istället för radbrytningar)

Vill ni kunna formatera text med html, och det inte är en admin (som man egentligen borde lita på) som har skrivit så får ni lite problem. Det är då bara att koda ett mer avancerat html-filter. Det är dock ganska komplext, men inte omöjligt."

Men koden ser ut såhär:

PHP:
1:
 
2:
<?php
3:
echo '<table><tr><td>';
4:
$result mysql_query('SELECT * FROM meddelanden ORDER BY id DESC');
5:
while($row mysql_fetch_assoc($result)) {
6:
   echo "<b>Meddelande #" $row['id'] . "</b><br />";
7:
   echo nl2br(htmlentities($row['meddelande'])) . "<br />";
8:
}
9:
mysql_free_result($result);
10:
echo '</td></tr></table>';
11:
?>
12:
 


Bara om du kan ändra så man kan ta del av din kod =)


Jag är nyfiken på vad du vill? Ta del av mitt mer avancerade filter? Vilken kod? Vad vill du ta del av?

För vill du ta del av mitt mer avancerade filter html-kod så kommer du få problem. Jag har kodat några sådana tidigare, men dom har varit väl inbakade i validatorklasser, samt varit beroende av andra delar av applikationen. Dels så hittar jag dom inte nu.

Men denna guide handlar inte om hur man ska göra, denna guide handlar om hur man inte ska göra, och vad man ska tänka på. Få upp ögonen för säkerhet.

Försök gärna koda detta filter själv om du behöver. Det ger en bra utmaning som man lär sig mycket på. Du kan få hjälp på vägen genom att fråga i PHP-forumet, och när du är klar är det välkommet att skriva ut i Tips & Trix så andra kan ta del av det du kodat.


Jo men jag klagar inget på vad du har skrivit och berättat för det är super.

Men jag la bara märket att du hade skrivit:
"(lägg märke till att nl2br körs efteråt, annars kommer alla <br> synas på sidan som text istället för radbrytningar)"

fast på koden du visar ligger nl2br _före_ och inte efteråt som du skrev. Kanske bara ett slarv fel eller så inget stort men om folk läser kan dem få in fel info, förstår du där?

Annars super tack för det, har hjälp mig mycket =)
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande MSN Messenger
pengi
Ex-Moderator



Medlem i: 4459 dagar
Från: JO57XQ
Status: Offline



#646330
Inlägg Skrivet: 2009-07-11 15:32      Ämne: Citera

bds skrev:
Men jag la bara märket att du hade skrivit:
"(lägg märke till att nl2br körs efteråt, annars kommer alla <br> synas på sidan som text istället för radbrytningar)"

fast på koden du visar ligger nl2br _före_ och inte efteråt som du skrev. Kanske bara ett slarv fel eller så inget stort men om folk läser kan dem få in fel info, förstår du där?

Annars super tack för det, har hjälp mig mycket =)


Det är väldigt stor skillnad på ordning i koden och körordningen. Detta handlar om grundläggande programstruktur.

i funktionen $res = nl2br( htmlentities( $in ) ); så kommer först värdet av $in att stoppas in i funktionen htmlentities, för att resutatet av htmlentities kommer att stoppas in som värde i nl2br.

Man kan skriva om detta för att göra det tydligare:
PHP:
1:
 $tmp htmlentities$in );
2:
$res nl2br$tmp ); 


Dvs. det är hela tiden körordning som jag nämner, inte ordning i programkoden.

Vidare diskussion och förtydligande på detta kan du gärna ta i lämpligt forum. (körordning och syntax hänvisar jag till mjukstarten)
 

_________________
"Question everything. Never trust propaganda. Keep on hacking." - Phrack
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida
danieldoppsko



Medlem i: 3557 dagar

Status: Offline



#671225
Inlägg Skrivet: 2010-02-01 21:46      Ämne: Citera

Kan det vara till nytta att ha andra namn istället för dom vanliga, typ user, name, password etc i sin members-tabell? tex om man kallar alla kolumner för ord på swahili istället?
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
Imagetown.se



Medlem i: 4094 dagar

Status: Offline



#671229
Inlägg Skrivet: 2010-02-01 21:50      Ämne: Citera

danieldoppsko skrev:
Kan det vara till nytta att ha andra namn istället för dom vanliga, typ user, name, password etc i sin members-tabell? tex om man kallar alla kolumner för ord på swahili istället?


Visst kan det vara till nytta, men hjälper ju inte så mycket om det går att komma åt information_schema.
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
Peppe L-G



Medlem i: 4336 dagar
Från: Mullsjö
Status: Offline



#671231
Inlägg Skrivet: 2010-02-01 22:34      Ämne: Citera

Imagetown.se skrev:
danieldoppsko skrev:
Kan det vara till nytta att ha andra namn istället för dom vanliga, typ user, name, password etc i sin members-tabell? tex om man kallar alla kolumner för ord på swahili istället?


Visst kan det vara till nytta, men hjälper ju inte så mycket om det går att komma åt information_schema.

På vilket sätt kan det vara till nytta?
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande MSN Messenger
pengi
Ex-Moderator



Medlem i: 4459 dagar
Från: JO57XQ
Status: Offline



#671242
Inlägg Skrivet: 2010-02-01 23:50      Ämne: Citera

Då är det väl bara för användaren att köra allt i google translate, eller lära sig dessa ord på swahiili? Det är inte någon hemlighet hur det språket fungerar.

Sedan skulle jag kunna gisssa kolumnerna utan att något namn på kolumnerna om man har en tabell likt:

1, august13, August, Willhemsexempelsson, 243F87)8A987A, 98/A, 5
2, gretzzor43, Greta, Exempeldottir, 87)8A533987A, 93A, 1
3, 34kalle, Quarl, Quacksson, 833987342A, 3Agse, 1

Ofta går även SELECT * även om man inte vet namnen.

Security by obscurity är inte något att föredra. Det hindrar inte hackaren mer än marginellt, men hindrar för utvecklaren att hitta sina egna hål, så det kan slå tillbaka.
 

_________________
"Question everything. Never trust propaganda. Keep on hacking." - Phrack
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida
zocstyle



Medlem i: 4756 dagar
Från: Stockholm
Status: Offline



#681411
Inlägg Skrivet: 2010-05-27 10:25      Ämne: Citera

Nu har jag inte läst hela tråden utan bara första sidorna eftersom jag inte riktigt hinner, men jag ser att MD5 används på flera ställen. Vad jag har hört anser folk att MD5 är "mer eller mindre" knäckt och att man bör använda sha1 istället. Vad säger ni om detta? Jag är ingen säkerhets expert och vet därför inte, men sha1 bör väl vara bättre?

Dessutom, borde ni ta upp hur man saltar sina strängar man konverterar med md5 eller sha1, då detta gör det hela extra säkert.

Edit: Mycket bra tråd för övrigt pengi.
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida MSN Messenger
Peppe L-G



Medlem i: 4336 dagar
Från: Mullsjö
Status: Offline



#681420
Inlägg Skrivet: 2010-05-27 13:14      Ämne: Citera

zocstyle skrev:
Vad jag har hört anser folk att MD5 är "mer eller mindre" knäckt och att man bör använda sha1 istället. Vad säger ni om detta?

Jag är ingen expert, men jag kan hänvisa till ett inlägg av Walkman i alla fall.
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande MSN Messenger
GosseGlen



Medlem i: 3249 dagar

Status: Offline



#684020
Inlägg Skrivet: 2010-07-12 13:39      Ämne: Re: Vanliga säkerhetshål och lösningar Citera

pengi skrev:


SQL-injektion
Den vanligaste och farligaste av dom alla.

Fall:
Vi gör ett script för att hämta en nyhet från en databas.

Ni har säkert sett kod som liknar följande, och ni har kanske skrivit sådan själv:
PHP:
1:
<?php
2:
$news_id $_GET['news_id'];
3:
 
4:
$result mysql_query('SELECT * FROM news WHERE id='.$news_id);
5:
$newsrow mysql_fetch_assoc($result);
6:
mysql_free_result($result);
7:
 
8:
//Skriv ut $newsrow
9:
?>


Ni testar koden. Den funkar för ?news_id=1, den funkar för ?news_id=6, men den funkar inte för ?news_id=313, då det inte finns någon nyhet 313 än. Den gör sitt jobb då den hämtar rätt nyhet när ni frågar om den, och ni är oftast nöjda.


men vad händer om man gör följande?

Vi går till en länk t.ex. ?news_id=0%3B+DELETE+FROM+news (dvs: news_id är "0; DELETE FROM news")

i detta fall kan vi följa det ganska enkelt:
PHP:
1:
<?php
2:
$news_id '0; DELETE FROM news';
3:
 
4:
$result mysql_query('SELECT * FROM news WHERE id=0; DELETE FROM news');
5:
?>

Whops... där försvann alla nyheter... kanske inte det man ville.

Hur löser man det här då?

enkelt egentligen, gäller bara att man tänker på det.

I första exemplet så var det en siffra som man fick mata in. Kan man kolla att det endast är en siffra så blir det svårt att ta sig igenom. T.ex.
PHP:
1:
<?php
2:
$news_id $_GET['news_id'];
3:
 
4:
if(!is_numeric($news_id)) die('Felaktig indata');
5:
 
6:
//mysql_query och sånt här
7:
?>



jag förstod inte riktigt?

när jag försöker ta bort informationen i min databas som i exemplet
(/index.php?start=0%3B+DELETE+FROM+data) så får jag följande error:

Error fetching data
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DELETE FROM nya_sidor,10' at line 1

och när jag använder koden: if(!is_numeric($start)) die('Felaktig indata');
så får jag bara felmeddelandet, Felaktig indata..

finns det något annat sätt att skydda sig mot SQL-injektioner?
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
marabou
Administratör



Medlem i: 5217 dagar
Från: Sveriges framsida
Status: Offline



#684021
Inlägg Skrivet: 2010-07-12 13:53      Ämne: Re: Vanliga säkerhetshål och lösningar Citera

GosseGlen skrev:
Error fetching data
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'DELETE FROM nya_sidor,10' at line 1

och när jag använder koden: if(!is_numeric($start)) die('Felaktig indata');
så får jag bara felmeddelandet, Felaktig indata..

finns det något annat sätt att skydda sig mot SQL-injektioner?


Det är inte alltid det funkar med ovanstående injektion, men risken finns där. Man kan formulera om frågan för att få den att utföra något annat ändå.

Citat:
finns det något annat sätt att skydda sig mot SQL-injektioner?

Här har presenterats flera sätt att skydda sig, men jag brukar ha följande huvudregel:
Om du inte är 110% säker på vad som finns i dina variabler så måste de skyddas.
Jag skrev ett inlägg om detta i följande tråd:
http://www.phpportalen.net/viewtopic.php?p=683740#683740

Om du i din databas har ett fält med tal (t.ex. en "Antal"-kolumn) som är av typen INT eller liknande, då finns det ingen anledning att skicka med en sträng till MySQL när det bara får finnas tal i kolumnen.
Om du skickar med en sträng så kan det ju finnas risk för att användaren har lagt in bokstäver, eller tillochmed apostrofer ( ' ) vilket kommer leda till att hela frågan ogiltigförklaras (t.ex. syntax error) eller ger möjlighet att "hacka" databasen.

Dessutom, om kolumnen är av typen INT, FLOAT, DOUBLE, TINYINT eller liknande, så skall man ju inte omge värdet med apostrofer utan skriva siffrorna direkt i SQL-frågan. Här får du problem om du tillåter en sträng eftersom användaren kan modifiera din SQL-fråga efter egen smak.

Har man ett fält av ovan uppräknade typer bör man göra om värdet på variabeln till rätt typ innan man lägger in den i frågan:
PHP:
1:
<?php
2:
 
3:
// Hämta från postat formulär
4:
$antal $_POST['antal'];
5:
 
6:
// Se till att det är rätt typ
7:
if (!is_numeric($antal)) {
8:
  die('Du skrev inte ett tal');
9:
 
10:
// eller gör ett tal av det utan att fråga
11:
$antal = (int) $antal;
12:
 
13:
// eller detta sätt (nästan samma som ovanstående)
14:
$antal intval($antal);
15:
 
16:
$sql "SELECT * FROM ordrar WHERE antal = $antal";
17:
...


Är fältet av typen VARCHAR eller någon annan sträng-typ, se då till att escapea eller filtrera så den inte innehåller ogiltiga tecken.
Om strängen inte får innehålla HTML-kod, använd strip_tags, och sedan mysql_real_escape_string.
Om strängen bara får innehålla vissa typer av tecken, filtrera bort ogiltiga tecken, t.ex. med preg_replace. Om du har filtrerat bort ogiltiga tecken (så du vet exakt vilka tecken som finns i strängen) behöver du inte köra mysql_real_escape_string, men det skadar inte att göra det för säkerhets skull.

Sammanfattning:
Eftersom du vet vilka typer dina databasfält har så är det bara att kolla att dina variabler är av samma typ, och innehåller tillåtna tecken.
Är ditt fält ett tal, se till att göra om variabeln till ett tal. Är det ett "rubrikfält" (t.ex. av typen VARCHAR) så bör du inte tillåta HTML, kör då strip_tags eller nåt annat filter. Alla strängar skall köras genom mysql_real_escape_string om du inte har filtrerat bort apostroferna på annat sätt...
 

_________________
"Never argue with stupid people. They will bring you down to their level and beat you with experience."
- Mark Twain
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida
GosseGlen



Medlem i: 3249 dagar

Status: Offline



#684024
Inlägg Skrivet: 2010-07-12 14:11      Ämne: Re: Vanliga säkerhetshål och lösningar Citera

marabou skrev:

Sammanfattning:
Eftersom du vet vilka typer dina databasfält har så är det bara att kolla att dina variabler är av samma typ, och innehåller tillåtna tecken.
Är ditt fält ett tal, se till att göra om variabeln till ett tal. Är det ett "rubrikfält" (t.ex. av typen VARCHAR) så bör du inte tillåta HTML, kör då strip_tags eller nåt annat filter. Alla strängar skall köras genom mysql_real_escape_string om du inte har filtrerat bort apostroferna på annat sätt...


ah, då förstår jag bättre. tack ^^
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
GosseGlen



Medlem i: 3249 dagar

Status: Offline



#685595
Inlägg Skrivet: 2010-08-09 21:47      Ämne: Citera

jag läste att include() kan vara ett säkerhetshål.

gäller det bara exemplet eller är den här kodsnutten inte säker heller?

PHP:
1:
<?php include("hem/menu.php"); ?>


om jag till expm skulle använda den på min hemsida, vad skulle kunna hända?
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
Teodor



Medlem i: 3802 dagar
Från: Stockholm
Status: Offline



#685601
Inlägg Skrivet: 2010-08-09 22:00      Ämne: Citera

Att skriva som du gjort är ingen fara alls.
Faran uppstår när du inkluderar en fil där du låter användaren bestämma filnamnet;
PHP:
1:
<?php 
2:
$minfil $_GET['filen'];  //användaren har skrivit in "www.domain.com/farlig_fil.php"
3:
include($minfil); ?>


Då kan det gå illa
 

_________________
teodor.se
Till toppen på sidan
Visa användarprofil Skicka privat meddelande Besök användarens hemsida
GosseGlen



Medlem i: 3249 dagar

Status: Offline



#685610
Inlägg Skrivet: 2010-08-10 01:43      Ämne: Citera

Teodor skrev:
Att skriva som du gjort är ingen fara alls.
Faran uppstår när du inkluderar en fil där du låter användaren bestämma filnamnet;
PHP:
1:
<?php 
2:
$minfil $_GET['filen'];  //användaren har skrivit in "www.domain.com/farlig_fil.php"
3:
include($minfil); ?>


Då kan det gå illa


ah, då förstår jag Very Happy
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
RiffiRaffi



Medlem i: 2588 dagar

Status: Offline



#717835
Inlägg Skrivet: 2011-12-17 01:26      Ämne: Citera

Tack så mycket :)
 
Till toppen på sidan
Visa användarprofil Skicka privat meddelande
Visa tidigare inlägg:   
Skapa nytt inlägg   Svara på inlägget Gå till sida Föregående  1, 2, 3 ... , 9, 10, 11  Nästa
PHPportalen Forum Index » PHP
Hoppa till:  
Du kan inte skapa nya inlägg i det här forumet
Du kan inte svara på inlägg i det här forumet
Du kan inte ändra dina inlägg i det här forumet
Du kan inte ta bort dina inlägg i det här forumet
Du kan inte rösta i det här forumet
Du kan inte bifoga filer i detta forum
Du kan inte ladda ner filer från detta forum
Kontakta oss på adressen: info@phpportalen.net
Webbplatsen bygger i grunden på phpBB © 2001, 2002 phpBB Group

Modifieringar har senare gjorts i systemet av PHPportalen
Sid och logotypdesign skapad av Daren Jularic