Ik heb een pagina aangemaakt dat gebruikers gegevens kunnen bewerken maar er viel mij iets op dat je vanaf urlbalk andere regels (en ook ids wat nog niet bestaat) van tabellen kunt bewerken terwijl dat de bedoeling niet is of je voert zomaar bijvoorbeeld letters er achter id= dan zie je nog steeds geen foutmelding.

Hoe zorg ik er voor dat je geen id uit je hoofd kan invoeren en overbodige letters met andere leestekens blokkeren?

Dit helpt bij mij niet:
bindParam(1,is_numeric($_GET['id']))

en dit:
is_numeric(bindParam(1,$_GET['id']))


Beetje opgeschoond om het kleiner te krijgen:
<?PHP
session_start();
if (!(isset($_SESSION['user_login_status']) && $_SESSION['user_login_status'] != '')) {
header ("Location: index.php");
	}
		else 	{
		try {
$dbc = new PDO('mysql:host=localhost; dbname=', '', '');
	} catch (PDOException $e) {
	echo "Error: " . $e->getMessage();
	}
if(isset($_POST['submit_btn'])) {
	$query = "UPDATE tabel SET name=? WHERE id=?";
	$stmt = $dbc->prepare($query);
	$stmt->bindParam(1, $_POST['name']);
	$stmt->bindParam(2, $_POST['uid']);
	if($stmt->execute()) {
		echo "<script>alert('Record updated.');location.href='index.php'</script>";
	} else {
		die('Unable to update record.');
	}
} else {
try {
$query = "SELECT * FROM tabel WHERE id=?";
$stmt = $dbc->prepare($query);
$stmt->bindParam(1,$_GET['id']);
$stmt->execute();
$row=$stmt->fetch(PDO::FETCH_ASSOC);
$username = $row['user_name'];
$id = $row['id'];
	} catch(PDOException $e) {
	echo "Error: " . $e->getMessage();
	}
?>

<form id=".$row["id"]." action="" method="POST">
<input type="hidden" value="<?php echo $id; ?>" name="uid">
  <div class="container">

<div class="panel-heading">
<h3 class="panel-title">Gegevens</h3>
</div>
  <div class="panel-body">
    	<div class="row">
			<div class="col-md-6">
					<table class="table">		
					<tbody>

				<tr>
					<td>Naam</td>
					<td><input class="form-control" type="text" id="formGroupInputSmall" placeholder="Naam"name="username" value="<?php echo $username; ?>"/></td>
				</tr>
					</tbody>
					</table>
					<input class="btn btn-default"  type="submit" name="submit_btn" value="Bevestigen"/>
</form>
			</div>
		</div>
	</div>
  </div>
</body>
<?php
}?>
</html>
<?php
}
?>
Dan krijg ik wel toegang.
Dus dan werkt het...

Alleen jij ziet jezelf als een admin. Hoe moet een script dat weten?
Voor jouw script ben je een gebruiker ;-)

Lees nog eens terug en kom dan zelf eens met het antwoord?
Volgens mij begreep je mij verkeerd.

Je logt in en dan kan je werkstukken uploaden (upload heb ik nog niet) onder je eigen naam.
Ik heb een pagina met lijst staan wat allemaal zelf is aangemaakt, bij elke regel is er een button om gegevens te bewerken. Ik vond het gevaarlijk uitzien dat je vanaf adresbalk id kon aanpassen en werkstukken van andere kon zien/bewerken.

Ik denk dat user_id ergens anders moet staan. Zal even naar kijken.
Ik houd niet van functies die iets controleren, en tegelijktijd de waarde proberen te repareren zodat het resultaat wel geldig is. De enige goede manier (wat mij betreft) om het controleren of (bijvoorbeeld) een ($_GET) variabele correct is (een auto-increment id bevat), is door te kijken (!== aanpassen) naar de vorm:
<?php
function isIndex($in) {
    // noot voor puristen: $ accepteert één newline (\n) dus je doet er ook
    // verstandig aan dit soort input te trimmen
    return (preg_match('#^[1-9][0-9]*$#', $in) == 1);
}
?>

An tje op 16/05/2015 21:09:18
Nog een tactiek om ID-s te obfuscaten is door ze te door de MD5-functie te halen. Je krijgt dan een tekenreeks van 32 karakters als ID. Vervolgens kan je die terug laten rekenen door de database met WHERE-clause als:
WHERE `{tabelnaam}`.`id` = MD5("{die geobfuscate ID}")
Dan is het al lastiger om oplopende ID's te voorspellen voor de eindgebruiker.

Security through obscurity is nooit een goed ontwerpprincipe. Daarnaast heeft een enigszins tech savvy persoon deze "beveiliging" zo gekraakt.

Precies, zelfde als met base64_encode() iets 'versleutelen' en terugsleutelen.
Johan de wit op 16/05/2015 23:54:15

Dus dat raad je af. Is het niet beter om over te gaan naar POST functie en dan MD5 inschakelen?

Ik raad het niet af, maar als je ID's echt graag wilt obfuscaten (facturen, C.V's etc..) dan raad ik aan om een unieke hash te gebruiken je je per item aanmaakt. Uiteraard blijf je onderwater de ID (PK;AutoIncrement) gewoon nog gebruiken.
- Aar - op 17/05/2015 20:55:35

[quote="Johan de wit op 16/05/2015 23:54:15"]
Dus dat raad je af. Is het niet beter om over te gaan naar POST functie en dan MD5 inschakelen?

Ik raad het niet af, maar als je ID's echt graag wilt obfuscaten (facturen, C.V's etc..) dan raad ik aan om een unieke hash te gebruiken je je per item aanmaakt. Uiteraard blijf je onderwater de ID (PK;AutoIncrement) gewoon nog gebruiken.
[/quote]

Zo iets al uniqid()?
Johan: Don't do it! Clear your mind!

Een gebruiker toetst in wat hij wil intoetsen als url. Ook met md5, unique_id or whatever string er in.
Stop je energie in "WAT LAAT IK ZIEN AAN WELKE GEBRUIKER".

(Hoeveel moeite kost het om iemand van een slecht idee af te helpen - lieve hemel :O )

Reageren