开发者

Is placing data in an href safe?

开发者 https://www.devze.com 2023-03-31 12:24 出处:网络
I\'m wanting to pass data from one php page to another on click, and use that data in populating the linked page. At first I was going to use ajax to do this, but ran into trouble, and then realized i

I'm wanting to pass data from one php page to another on click, and use that data in populating the linked page. At first I was going to use ajax to do this, but ran into trouble, and then realized it was as easy as placing the data in the href of the link.

My question is, is it safe to place the data directly in the href in this manner? I know that passing the d开发者_Go百科ata via the URL (which this ends up doing) is safe, but I heard somewhere (that I can't recall), that placing the data directly in the href of a link can cause problems with web-crawlers and the like.

Is this true? Is there anything else I should worry about in using this method? Or is this the best way for me to send data, unique to each link, to another page on click?

The PHP:

while($row = mysql_fetch_assoc($result_pag_data)) { 
    echo "<a target='_blank' href='secondary_imgs.php?imgId=".$row['imgId']."'></a>";
}


There should be no problems with web crawlers as they just follow the links.

There is however a potential security problem in that malicious users can address arbitrary rows in your table by altering the URL string. This may or may not be a problems depending on what the links point to.

If you need to restrict your data to particular users then this is not a good idea, otherwise, its simple and straightforward if it works for you then do it.


I think it's safe enough if you want to display some data, but never use get method to insert data, especially careful when it comes to sql. NEVER use get method to modify sql, if had to, validify the arguments first.

Be careful with post method too. In a word, never trust users, you never know.


It looks like it's safe since you're "only" querying an image with a specific id (that's all you're doing, right?). Just ask yourself if

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

9.1.1 Safe Methods

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe".

applies.


Neither passing data through URL, nor embedding it into href is safe.

  • That data can be seen by user, so you are not protecting your data from user.
  • That data can be modified by user, so you are not protecting your data from modification and your script from getting evil or misformed parameters.

So, if you are designing the system which is going to be run under strict protection in a friendly environment - it's OK to pass params through the URL (hovewer, note that URL string is limited to 4096 characters). If not - it depends on protection level you want.

The simpliest way is to use POST requests instead of GET. THis way you'll not protect your data from evildoers, but ordinary users will not have the ability neither see nor modify it. Anyway, it's a good idea to validate the input on the server always.


Define "safe".

Without knowing the the threat model is nor how the data is used it's impossible to answer.

Certainly there are very important differences between a GET and POST (but note that a POSTed for can still send GET variables via the action URL).

It's no less dangerous using a POST rather than GET to send data. Nor using a cookie. All can be modified at the client end.

If you're talking about CSRF, then there's lots of methods to prevent this - try Google for starters.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号