URL Güvenlik

2 Cevap php

Ben URL'lerin güvenlik fonksiyonu aşağıda yaptık. Ben sadece bilmek istedim i yeniden düşünün ya da aşağıdaki kodu değiştirmek için gereken bir şey var. Çeşitli kaynaklardan güvenliğe oldukça bazı makaleleri okuduktan sonra bu fonksiyonu yaptık.

İşte fonksiyonudur:

// filters possible malacious stuff from URLs
private function filter_url($url)
{
  if (is_array($url))
  {
	foreach($url as $key => $value)
	{
		// recurssion
		$url[$key] = filter_url($value);
	}

	return $url;
}
else
{
	// Allow only one ? in URLs
	$total_question_marks = substr_count($url, '?');

	if ($total_question_marks >= 2)
	{
		exit('You can not use 2 question marks (?) in URLs for security reasons!!');
	}

	// decode URLs
	$url = rawurldecode($url);
	$url = urldecode($url);
	// remove bad stuff
	$url = str_replace('../', '', $url);
	$url = str_replace('..\\', '', $url);
	$url = str_replace('..%5C', '', $url);
	$url = str_replace('%00', '', $url);
	$url = str_ireplace('http', '', $url);
	$url = str_ireplace('https', '', $url);
	$url = str_ireplace('ftp', '', $url);
	$url = str_ireplace('smb', '', $url);
	$url = str_replace('://', '', $url);
	$url = str_replace(':\\\\', '', $url);
	$url = str_replace(array('<', '>'), array('&lt;', '&gt;'), $url);

	// Allow only a-zA-Z0-9_/.-?=&
	$url = preg_replace("/[^a-zA-Z0-9_\-\/\.\?=&]+/", "", $url);

	//print $url;
	return $url;
  }
}

Ben sadece böyle bu işlevini kullanabilirsiniz:

$_GET = filter_url($_GET);

Ya da böyle:

$_SERVER['QUERY_STRING'] = filter_url($_SERVER['QUERY_STRING']);

2 Cevap

Bu gibi catch-all filtre çeşit denemek ve oluşturmak için herhangi bir girişimi, her zaman başarısız ve ek olarak, gerçekten bir "dissalowed ile bir parça veri kabul etmek gerektiğinde her zaman" bozuk "verilerine yana, sorun olacak olacak "karakter veya karakter dizisi.

Eğer gerçekten web güvenliği konuyu bir parça etrafında okuma ve tam örneğin (minimum) cross-site scripting, cross-site istek sahtecilik ve SQL enjeksiyonu gibi ortak saldırıları anlamak gerekir.

Güvenli bir şekilde kullanıcı tarafından sağlanan verileri kullanarak bir 2-yönlü bir yaklaşım almak gerekir. Bu etmektir

Bu gibi sürecin düşünün:

  1. Doğrulamak ve içeri yolda verileri reddetmek
  2. Çıkarken Encode veri

Input Validation Check each piece of input to ensure it only contains the right kind of data and fit within length and range boundaries -- ACCORDING TO THE MEANING OF EACH INIDIVIDUAL PIECE OF DATA --. i.e. ensure numbers only contain numeric digits. ensure years are within a sensible range, ensure strings are not overlong or blank, ensure filenames don't travese directories, ensure IDs only contain legal characters. etc.etc. etc.. The most important thing here, is wherever possible state what is allowed; DO NOT STATE WHAT IS DISSALOWED. Testing for what is allowed and rejecting everything else is known as whitelisting and is a good thing, as you know you will get clean data (or as near to it as is sensible). Looking for bad patterns and rejecting them is known as blacklisting and is a less safe idea. For black-listing to succeed, you need to ensure that your black-list is complete, and often this is basically an impossible task. In some limited contexts a black-list approach can be ueful, but only when you are as certain as you can be that the list is exhaustive.

Storing the data Once you have only accepted clean data, save it in your variable or session. Maybe take an approach to variable-naming that indicates this data is now clean. The most important thing here, is that when we save this data, we have not yet changed it. This means that the data can be used in any context without us having "thrown anything away"

Output encoding When you send the data to an external system - such as a filename, cookie, web page, file or saving in your own database - you must encode the data to ensure you do not break the language syntax or file format used in the output. It is here where the data can be transformed.

Eğer veriler üzerinde gerçekleştirmek için gereken dönüşüm nasıl ve nerede verileri kullanmak göre farklı olacaktır. Bir windows dosya kullanım için bir dize Dönüşümü farklı bir linux dosya için farklı tekrar bir PDF belgesi sokulmadan varsa, ya da web sayfası veya veritabanı vs vs vs Ancak, daha ayrıntılı olarak 2 örneklere bakalım:

Output to HTML In the most common case of inserting a string into some HTML, you need to ensure that you do not allow the user to inject arbitrary content into the page, Not only does this allow them to edit the page that another user can see, but they can also inject code in the form of javascript that could do anything they want. This script will run as the user that views the page and could allow the attacker to steal their information and login credentials. This is called Cross-Site Scripting. The syntax rules of HTML and Javascript mean that you need to encode differently depending on where in the HTML you insert the user-data. There is a very valuable page at http://www.owasp.org/index.php/XSS%5F%28Cross%5FSite%5FScripting%29%5FPrevention%5FCheat%5FSheet that explains how to transform the data for the 6 different categories of places where you can insert a string into a HTML page.

Output to database If you save user-data to the database, you effectively have to include the string in an SQL statement. You must ensure that you do not allow the user to change the meaning of the SQL statement and only be able to change the data values. If they can change the meaning of the statement, this is called SQL injection.

Bu, bu çıkışı-kodlamayı kullanarak sorunu çözebilir rağmen, sen "bağlı parametreleri" adı verilen bir teknik kullanarak daha iyi, özel bir durumdur. Bu veritabanına konuşurken veri her zaman veri olarak ve asla kod olarak kullanılmasını sağlar. PHP "PDO" (cross-database) ve "mysqli" (MySQL) gibi db kütüphanelerin bir dizi bağlı parametreleri destekler. Bu "Mysql" kütüphane bağlı-parametreleri desteklemiyor unutulmamalıdır.

Orada cross-site scripting (XSS) ve SQL enjeksiyonu ve (SQLi) hakkında tüm net üzerinden ve StackOverflow çok daha fazla bilgi ve bu konu etrafında okumaya değerdir. Orada saldırının diğer birçok türde elbette vardır, ama takip ederseniz yukarıdaki süreç riskleri en aza indirmek gerekir. Bu veri doğrulama ve kodlama rutinleri güvenli bir web appplication önemli bir kısmını telafi etmek için mantıksız değil. Ama sizin standart çalışma süreci içine güvenlik metodoloji biuld var. Sonradan ekleyerek çok daha zordur. Bazen belirli bir işlev için doğrulama kodu geri bakmak ve biraz daha fazla kural ekleyebilirsiniz olmadığını düşünüyorum. Her zaman ilk seferde kaçırmak şey olması oluyor.

Blacklists dayanarak filtreler başarısız. Eğer saldırı modellerini tespit konusunda ciddi iseniz PHPIDS edin.

etiketler