PHP Security - GET Variables, URL safe?
I am creating a very basic iPhone simulator and what I want to do is just have it in one location, and then any site that we have and want to put it on, we would just call it using: http://www.example.com/iphone-test.php?url=http://www.example.com/mobile/
Is there anything I need to look out for that could be un-safe? There is no database involved or anything, but just in case someone wanted to mess around and put some stuff in the URL, what are some things I can do to help make this a little more safe?
Here is my code:
<?php
if(isset($_GET['url'])) {
$url = $_GET['url'];
?>
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>iPhone Test</title>
<style type="text/css">
#iphone {
background:url(iPhone.png) no-repeat;
width:368px; height:706px;
position:relative;
overflow:hidden;
}
#iphone iframe {
position:absolute;
left:30px;
top:143px;
border:0;overflow:hidden;
}
</style>
</head>
<body>
<div id="iphone">
<iframe src="<?=$url;?>" width="307" height="443"><p>Your Browser does not support iFrames.</p></iframe>
</div>
</body>
</html>
<?php
}
?>
Edit: Thanks for all of your help. I did some research and here is what I have so far:
<?php
include开发者_JS百科_once 'filter.php';
$filter = new InputFilter();
if(isset($_GET['url'])) {
if (filter_var($_GET['url'], FILTER_VALIDATE_URL)) {
$url = $filter->process($_GET['url']);
?>
Source: http://oozman.com/php-tutorials/avoid-cross-site-scripting-attacks-in-php/
Class: http://www.phpclasses.org/browse/file/8941.html
What do you think?
You should use PHP's filter_var to check it's valid...
if (isset($_GET['url'])) {
if (filter_var($_GET['url'], FILTER_VALIDATE_URL)) {
$url = $_GET['url'];
}
}
If this page is accessible for anyone to access then you are opening yourself up to XSS and Phishing redirects. For example, try adding this to your URL params:
?url="></iframe><script>alert(123)</script>
In Firefox 6.02 that fires off the alert. Which means that any JS could be fired and used to redirect users who think they are visiting your site. Or it could be used to steal cookies that are not marked HTTPOnly.
This can be mitigated by encoding for HTML attributes. Which is described here from OWASP:
Except for alphanumeric characters, escape all characters with ASCII values less than 256 with the &#xHH; format (or a named entity if available) to prevent switching out of the attribute. The reason this rule is so broad is that developers frequently leave attributes unquoted. Properly quoted attributes can only be escaped with the corresponding quote. Unquoted attributes can be broken out of with many characters, including [space] % * + , - / ; < = > ^ and |.
Reference: https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes
Now, for your other issue that the above will nto address. If you allow just any arbitrary URL to be entered, then there is nothing stopping someone from doing something like this:
?url=http://myevilsite.com/redirect.php
And have that page redirect the user:
window.top.location.href = "http://www.site.com";
The only thing you can do about that is to use a white list of acceptable URLs.
The request method does not provide any securiy features, please see this answer
You need to be 100% sure beyond doubt that your code will not hijack that frame with javascript or lead the person to a malicious domain, or lead to a request form on your page that does something they don't want.
You can see some examples out here of that:
<IFRAME SRC="javascript:alert('XSS');"></IFRAME>
<iframe src=http://ha.ckers.org/scriptlet.html"></IFRAME>
You could have the person lead to post something as well...
Anyway, I can steal all your cookies, or trick the user into thinking they're still on your site but really be on mine where I get all their precious information.
Just stop, before you go any further you need to know what your doing, and you start by reading this.
You are vulnerable to cross site scripting.
All someone has to do is include "></iframe><script>EEEEVVvvvillll!!!! in the URL, or use a non-HTTP/HTTPS URI.
Here is a list for the security concerns involved here..
IFrames security summary
Wednesday, 24 October 2007 I’ve decided to collect the various proof of concepts I’ve done and summarise why iframes are a security risk. Here are the top reasons:-
- Browser cross domain exploits
Description:- Because you can embed another web site inside your page, you can exploit that page and perform actions as that user and doing anything on a chosen web site.
Proof of concept:- Safari beta 3.03 zero day
- XSS/CSRF reflection attacks
Description:- Using iframes embedded onto a compromised site an attacker then can reflect attacks to other servers therefore making attacks difficult to trace and having a focal point to conduct attacks.
Proof of concept:- None available for this type of attack as it would be difficult to show the method without actually conducting an attack.
- CSS and iframes can scan your LAN from the internet!
Description:- By exploiting features in CSS and using iframes to check if the default IP address exists, it’s possible to get your network address range quite easily providing the network device uses the default out of the box IP address.
Proof of concept:- CSS LAN scanner
- LAN scanning with Javascript and iframes
Description:- Using a similar method as above it is possible to gain your LAN information using Javascript.
Proof of concept:- Javascript LAN scanner
- CSS iframe overlays
Description:- Iframes can be embedded inside each other in Firefox and you can alter their appearance to create seamless overlays with any site. This would make it very difficult for a user to know which site they are interacting with and fool them to performing an action.
Proof of concept:- Verisign OpenID exploit (now fixed)
- URL redirection
Description:- Iframes also allow you to perform redirection so you can have access to URLs which normally wouldn’t be accessible. In the delicious example, the POC redirects from delicious/home to your account bookmarks and then uses CSS overlays to display your first bookmark. Firefox and a delicious account are required for the POC.
Proof of concept:- Delicious CSS overlay/Redirection
Original here
You could make it a lot safer by acting like a proxy, load up the requested URL in PHP, strip everything out of the HTML (javascript etc) and then display it in the iframe pointed at a webpage on your server
Simply use strip_tags(), to void any evil script entry:
$url = strip_tags($_GET['url'])
加载中,请稍侯......
精彩评论