AdminCP Skin Search & Replace

[Tmod700]

You could make the Skin Search & Replace actually useful to us that want to use it to change code in the skins.

For example I copied a line from the global_board_footer and pasted it into the search box and it couldn't find it, Why not I just copied it from the template itself.

Very weak tool in my opinion.

Tmod

[CharlesC]

I never found anything so checking "Search in selected set and all parents including the master set." off usually finds what I need.

[Tmod700]

Ok I am updating my board from 2.3.3 to 2.3.4 and there are only a couple of template changes but I have 25 skins that I need to update.

I tried searching for the string below.

global_dst_check(parseInt("{$this->ipsclass->member['time_offset']}"),parseInt("{$this->ipsclass->member['dst_in_use']}") );

This will come back as it cannot find it even though I copied it from that skin and I did try the "Search in selected set and all parents including the master set." and either way it still cannot find it.

Tmod

[elj]

I've found that the feature is pretty useless and doesn't work well at all.

[Tmod700]

Ok you looking at this IPB?

That is two that say it ain't worth a hill of beans.

Tmod

[bfarber]

Well, I understand where you're coming from, but all those special characters and such are usually why you aren't finding anything. The quotes and brackets and everything else sometimes get escaped or converted in the input and so on. If you search for something simpler, such as "global_dst_check" in the example you provided, will usually yield better results.

[.Ryan]

I've found that the feature is pretty useless and doesn't work well at all.

Exactly why can't it be made to search for the exact bit of text we are looking for? The few times I tried to use it it doesn't work and its a pain...

[Tmod700]

Well, I understand where you're coming from, but all those special characters and such are usually why you aren't finding anything. The quotes and brackets and everything else sometimes get escaped or converted in the input and so on. If you search for something simpler, such as "global_dst_check" in the example you provided, will usually yield better results.

But you also need to understand that the trimmed down code that you refer to may exist on several different templates and then we have to go on a search and destroy mission to find the exact code that we want to change.

Also when you select search and replace how can you search for a code that contains characters and then replace it with something that contains characters when you can't use characters?

Makes zero sense to me that IPB would even implement this as it is of zero value.

Tmod

[Tmod700]

I was just asked to make some changes on a IPB 1.3 board and the search function there is alot better then it is on 2.3.4, Why is it we regress as the version numbers go up. If the search feature in 1.3 will find those odd characters why won't 2.3.4?

Tmod

[henke37]

The quotes and brackets and everything else sometimes get escaped or converted in the input and so on.

Yeah, about that, that is a defect. Stop doing that and so on. Escape when needed to, not before you even know the task to do.

[bfarber]

Yeah, about that, that is a defect. Stop doing that and so on. Escape when needed to, not before you even know the task to do.

Actually, I'd whole-heartedly disagree.

While the issue posted above is a bug, and I don't disagree could/should be fixed, I was merely providing some insight as to what the problem likely was and providing a method that could help the poster get going in light of the issue. I wasn't giving an excuse as to what the problem was.

However, part of the reason IPB is secure against attack is because of the fact that it automatically escapes input 99% of the time (we can't escape all input automatically, such as data posted in topics for instance). I wouldn't agree we should try to remove the automated methods of escaping data and then individually ensure each time input is used in a file that it should be escaped. That would be tedious and extremely prone to human error (such as overlooking a field somewhere).

[henke37]

However, part of the reason IPB is secure against attack is because of the fact that it automatically escapes input 99% of the time (we can't escape all input automatically, such as data posted in topics for instance). I wouldn't agree we should try to remove the automated methods of escaping data and then individually ensure each time input is used in a file that it should be escaped. That would be tedious and extremely prone to human error (such as overlooking a field somewhere).

Sorry, but me having to tell YOU that the input for the topics is escaped too isn't good looking. But it is done.

And, yes I do think that manual escaping is important. It is not just about security, it is also a matter of data quality!
Any transformation done on data will change it. (Well, duh!) The issue is that in the end, you want to work with the raw data, not some escaped into hell thing that kinda resembles it.

I'd like to introduce you to a prime example of exactly this behavior(preemptive escaping of everything) and how it went. A certain application automatically escaped the input too all the user provided scripts by default. This lead to strange bugs when the scripts wanted to use the raw data and did not plan on using the data where the escaping would have made sense. It also lead to a big hassle of having to unescape the data depending on the runtime settings.
In the end, they decided to drop support for this escaping and all the people working with the application was happy that they no longer had to fix the broken input. Of course, they still had the responsibility to properly escape the data, but the automagical escaping that was done for them didn't do all escaping tasks, no, it only did the escaping for only one specific format. The people who thought that this was enough was writing insecure code. Now, this may sound like a boring irrelevant application, but no, this is THE most relevant application for this case. I am talking about PHP itself!

If the PHP developers thought that magic quotes was a bad idea and that it should be killed, maybe you should learn from it! The facts remains:

• One size does not fit everybody. People still got xss vulnerabilities and SQL injections because it didn't work properly because it was not specific enough.
• Doing it for people when it is not necessarily is a data corruption and a waste of cpu time
• People relaying on it solely gets a false sense of security. And know what? You are suffering from the same syndrome with the automagical escaping in ipb!
  

Treat data as different datatypes! Do never ever try to use a URLString as a HTMLString and so on. A lot of the abuse of dataformats in today is never caught, because it works good enough. Until the edgecases comes! Don't fall victim to the "kinda works when I do some simple tests" methodology!

[henke37]

Also, there is tools avalible for finding use of wrongly escaped data.

[henke37]

Here is a tool for finding improperly escaped data:
http://wiki.php.net/rfc/taint/

[bfarber]

Sorry, but me having to tell YOU that the input for the topics is escaped too isn't good looking. But it is done.

What do you mean? All data is escaped. Now, posted topic submissions (I assume you mean such as a new topic "post" or a reply "post") we access the raw $_POST data, not the data transformed into ipsclass->input. In this case, the normal escaping is not done - we DO remove some things (I'd have to load the file up, but off the top of my head I think it's just null bytes and diretory traversal character sequences), but not the same as what is in ipsclass->input (i.e. ! to it's html entity).

And, yes I do think that manual escaping is important. It is not just about security, it is also a matter of data quality!

Any transformation done on data will change it. (Well, duh!) The issue is that in the end, you want to work with the raw data, not some escaped into hell thing that kinda resembles it.

See, that's kind of where we diverge. WE want to work with the data that we've removed special characters from. In the rare instances that we want the raw data, we use the raw data (i.e. $_POST['Post']), but in most other cases our escape routines are sufficient for what we are doing.

I'd like to introduce you to a prime example of exactly this behavior(preemptive escaping of everything) and how it went. A certain application automatically escaped the input too all the user provided scripts by default. This lead to strange bugs when the scripts wanted to use the raw data and did not plan on using the data where the escaping would have made sense. It also lead to a big hassle of having to unescape the data depending on the runtime settings.

In the end, they decided to drop support for this escaping and all the people working with the application was happy that they no longer had to fix the broken input. Of course, they still had the responsibility to properly escape the data, but the automagical escaping that was done for them didn't do all escaping tasks, no, it only did the escaping for only one specific format. The people who thought that this was enough was writing insecure code. Now, this may sound like a boring irrelevant application, but no, this is THE most relevant application for this case. I am talking about PHP itself!

Magic quotes is an entirely different beast. :P One php installation may have it on, another may have it off. Developers learned to code sloppily between magic quotes and register globals because they could - and they thought they were safe. In the end, it caused more damage than it helped, especially for those trying to distribute applications.

On the other hand, we don't provide settings to turn our escape routines on and off. And you can still access the "raw" (minus the minor escaping referenced above) data if you need it. If you are a developer utilizing IPB, that would be up to you to determine.

Treat data as different datatypes! Do never ever try to use a URLString as a HTMLString and so on. A lot of the abuse of dataformats in today is never caught, because it works good enough. Until the edgecases comes! Don't fall victim to the "kinda works when I do some simple tests" methodology!

I don't disagree here at all. Our escape routines are not meant as a one-thing fits all. When we want a url, we attempt to validate it as a url. When we want an email address we validate it as an email address. When we want an integer, we intval it (and in many cases, further confirm the result is greater than 0, as negatives are still integers). Our escape routines that are referenced here are not the end-all-be-all in the application to escape input. They are a primary initial layer to build upon, depending on the datatype you are trying to work with. And again, when the raw data is needed, it's still available. We don't wipe out _GET/_POST/etc.