webForumDet fria alternativet

Sårbarhet mot sql injection

15 svar · 1 938 visningar · startad av zarabud

zarabudMedlem sedan sep. 201033 inlägg
#1

Har en sida som jag inte har haft tid att uppdatera så mycket. Nu vill jag starta liv i den, men idag ser den förfärligt ut och har fått många fel, jag antar att sidan har varit ett lätt byte för olika attack försök med sql injection. Jag har själv skickat en sgl injection och fick tillbaka olika sgl felmeddelanden(Se bifogade exemplar på meddelandet) och all information som är sparat på databas.
Jag skulle uppskatta om någon här kunde enkelt steg för steg förklara hur ska jag gå tillväga för att lösa databasproblemet.

-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 ''39''' at line 1
- 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 'Tables Group By x)a) /*'' at line 1
- 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 ''1098''' at line

clarkbonesMedlem sedan feb. 20012 693 inlägg
#2

Börja med att skriva ut sql-strängen som skickas mot databasen...

och lägg upp koden som skapar sql-strängen

civilpolisenMedlem sedan dec. 2009816 inlägg
#3

Enklast är väl att se till att ingen SQL fungerar utifrån de formulär som finns på hemsidan.

Men det är ju så det är för du får ju ett felmeddelande.

' ## TRIM VARS
FUNCTION trimVars(myVar)
	tmp = request(myVar)
	tmp = replace(tmp, "|", "")
	tmp = replace(tmp, "'", "''")
	trimVars = tmp
END FUNCTION

Nu är detta Klassisk ASP men du får göra samma med din in-data fält, dvs. plocka bort alla raka sträck och ersätta alla enkla enkelfjumpar med dubbla enkelfjumpar.

Med detta enkla trick fungerar inga SQL injection.

Are you with!? :-)

aasahMedlem sedan mars 20033 451 inlägg
#4

Jag har själv skickat en sgl injection och fick tillbaka olika sgl felmeddelanden(Se bifogade exemplar på meddelandet)...

Om nedanstående felmeddelanden är det du fick tillbaka, så har du inte skickat några Injections, bara ogiltig SQL. (OBS! andra bokstaven är ett Q för Query inte ett g).

Läs mer om SQL Injections, vad det är, hur det fungerar och hur man undviker det här (på svenska) eller stoppa in orden SQL Injections i Google och tryck på sök...

clarkbonesMedlem sedan feb. 20012 693 inlägg
#5

civilpolisen skrev:

Med detta enkla trick fungerar inga SQL injection.

Du har tyvärr fel. Hackern kan skicka in tecken hexadecimalt och då funkar inte din filter funktion...

onkelborgMedlem sedan juli 2003582 inlägg
#6

Parameteriserade sql-frågor

civilpolisenMedlem sedan dec. 2009816 inlägg
#7

clarkbones skrev:

Du har tyvärr fel. Hackern kan skicka in tecken hexadecimalt och då funkar inte din filter funktion...

Intressant poäng. Det argumentet har jag aldrig sett tidigare.

***
Jag tänker, att den som arbetar med system som är attraktiva i ful-kretsar får väl göra en sök och ersätt även med hexadecimala alternativ.

Det har jag aldrig reflekterat över, faktiskt. Men jag håller på med ett projekt där det finns anledning att reflektera över detta!

onkelborgMedlem sedan juli 2003582 inlägg
#8

Parameteriserade sql-frågor, _inte_ replace och stoppa in en massa variabler direkt i sql-frågan. Du kommer missa någonting special för någon databas någonstans i någon fil i något projekt annars, jag lovar

clarkbonesMedlem sedan feb. 20012 693 inlägg
#9

civilpolisen skrev:

Intressant poäng. Det argumentet har jag aldrig sett tidigare.

***
Jag tänker, att den som arbetar med system som är attraktiva i ful-kretsar får väl göra en sök och ersätt även med hexadecimala alternativ.

Det har jag aldrig reflekterat över, faktiskt. Men jag håller på med ett projekt där det finns anledning att reflektera över detta!

Onkelborgs parameteriserade sql-frågor är en bättre lösning hursomhelst...

zarabudMedlem sedan sep. 201033 inlägg
#10

Tack för alla svar. Tyvärr jag måste erkänna att jag inte hänger med, därför jag har ingen kunskap om databaser. Hur som helst jag googlar nu och läsa på för att se om jag kan klarar uppgiften i annars måste jag anlita någon som kan göra jobbet.

Zara

civilpolisenMedlem sedan dec. 2009816 inlägg
#11

Ja, det var mycket technosnack här, det är jag benägen att hålla med om.
Vad är det du inte förstår?

Så här fungerar SQL injection: Det betyder att man skickar SQL kommando till databasen, men från utsidan.

Exempel, en gästbok:

Namn: Civilpolisen
Meddelande: Jag skriver en hälsning i din gästbok!!

Jag skriver en hälsning i din gästbok!!
Civilpolisen

Namn: Civilpolisen
Meddelande: SELECT strPassword, strEmail FROM [users]

adam123 inge@smart.se
adam456 mera@dumt.se
adam789 jätte@korkat.se
Civilpolisen

Alltså... SQL injection betyder att du skickar in ett SQL kommando och får reda på spännande grejer baserat på detta. Det förutsätter att den som skickar ful-inlägg vet hur databasen ser ut, men det är kanske inte alltid så svårt... Det går att gissa sig till. Det är bara att pröva!!

Var det detta du frågade efter?

zarabudMedlem sedan sep. 201033 inlägg
#12

civilpolisen skrev:

Ja, det var mycket technosnack här, det är jag benägen att hålla med om.
Vad är det du inte förstår?

Jag vet lite om SQL injection och det har jag använt mot min webb med hjälp av programmet Havij, Men min fråga är hur man skyddar sig mot den här typen av attacker när webben är sårbar mot SQL injection.

Zara

civilpolisenMedlem sedan dec. 2009816 inlägg
#13

Ja... Jag skrev ovan hur du gör för att plocka bort enkelfjumpar och långa streck.
Det är ju en bit på vägen, om än inte 100% vattentätt för den som verkligen vill.

Ett annat tips kan var att följa med i diskussionerna på https://www.flashback.org
Där finns en hel del att studera för den som vill fördjupa sig inom i ett visst ämne!

zarabudMedlem sedan sep. 201033 inlägg
#14

civilpolisen skrev:

Ja... Jag skrev ovan hur du gör för att plocka bort enkelfjumpar och långa streck.
Det är ju en bit på vägen, om än inte 100% vattentätt för den som verkligen vill.

Ett annat tips kan var att följa med i diskussionerna på https://www.flashback.org
Där finns en hel del att studera för den som vill fördjupa sig inom i ett visst ämne!

Tack för tipset Civilpolis, Jag ska försöka med ditt tips och samtidigt följa diskussionerna på forumet i flashback.

Tack än en gång för det.

zarabudMedlem sedan sep. 201033 inlägg
#15

Jag kunde inte lösa problemet, databasen skickar fortfarande följande meddelande.

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 'd41d8cd98f00b204e9800998ecf8427e'' at line 1

Undrar vad måste ändras i login filen som ser så här:

<?php
		
if(isset($_POST['login']) && $_POST['login']=='Submit'):
	# check if already logged in!!
	if(check_logged_in()):
		$login_session->pass_msg[]=MSG_LOGIN_ALREADY_LOGGED_IN;
		$login_session->set_pass_msg();
		Redirect(make_url('myaccount'));
	endif;
	//print_r($_POST);exit;
	#set validations;
	$validation= new user_validation();
	$validation->add('email', 'req');
	$validation->add('email', 'email');
	$validation->add('password','req');
	$validation->add('password','wrong');
	#check set validations.
	$valid= new valid();
	if($valid->validate($_POST, $validation->get())): # if true then all is ok..proceed.
		$Query->InitilizeSQL();
		$Query->TableName='user';
		$pass=md5($_POST['password']);
		$Query->Where="where username='$_POST[email]' and password='$pass'";
	
		# such user exists.
		if($user=$Query->DisplayOne()):
			# set logged in and redirect to needed page.
			$login_session->user_id=$user->id;
			$login_session->verified=$user->is_email_verified;
			$login_session->set_user_id();
			$login_session->username=$user->username;
			$login_session->set_username();
			$login_session->name=$user->firstname;
			$login_session->set_name();

			#Update total visits
			$Query->InitilizeSQL();
			$Query->TableName='user';
			$Query->Data['id']=$user->id;
			$Query->Data['total_visit']=$user->total_visit +1;
			$Query->Update();
			#redirect			
			Redirect(make_url('myaccount'));
		else:
			# not such user exists.
			$login_session->pass_msg[]=MSG_LOGIN_INVALID_USERNAME_PASSWORD;
			$login_session->set_pass_msg();
			$login_session->set_error();
			Redirect(make_url('login'));
		endif;
	else:
		$login_session->pass_msg=$valid->error;
		$login_session->set_pass_msg();
		$login_session->set_error();
		Redirect(make_url('login'));
	endif;
endif;
?>
spangoMedlem sedan juni 20006 147 inlägg
#16

zarabud skrev:

Tack för tipset Civilpolis, Jag ska försöka med ditt tips

Det tycker jag du ska låta bli, att bygga upp SQL med strängkonkatenering och göra replace på "skadliga" tecken är en genomusel idé av bland annat dessa skäl:

  1. Du kan aldrig vara helt säker på att din replace tar bort allt som kan ställa till det.
  2. Du kan aldrig vara helt säker på att du minns att använda replacen på alla ställen där den behövs.
  3. Det ger svårläst och ineffektiv kod.
  4. Med just det förslag som gavs ovan förstör du användarnas input. (Tänk om nån faktiskt behöver skriva in ett | någonstans?)

Allt detta slipper du om du använder parametriserade frågor (vilket är det vi som jobbar med sånt här på riktigt använder). "Technosnack"? Nej, förnuft...

Hursomhelst, om du vill ha ett fungerande loginscript skulle jag rekommendera att du följer onkelborgs och clarkbones råd tidigare i tråden och läser på lite om parametriserade frågor: http://se.php.net/manual/en/mysqli.quickstart.prepared-statements.php

Det är inte svårare att skriva än sök-och-ersätt. Det är lättare att läsa än sök-och-ersätt. Det är kort och gott alltid bättre än sök-och-ersätt.

Genererad på 396 ms · cache AV · v20260730165559-full.f96bc7eb