Re: [PHP] Check the byte sequence of a file to tell if it is UTF-8 without the BOM using PHP ?

[Peter Lind]

On 22 May 2011 08:17, Eli Orr (Office)  wrote:
> Hi Adam,
>
> I have a prof that the XML advise does not work in real cases I had.
> We are using XMLs in our system but when you edit the XML with  a text
> editor and put the XML heading of UTF-8
> 
>
> it DOES NOT assure the text inside is encoded in UTF-8 so but maybe (many
> cases) t other iso-xxx method.

The point of the header is telling readers what encoding is used. Of
course that means errors are possible - setting the header is not
magic, it doesn't change the rest of the file. You need to make sure
the contents of the file match the encoding from the header when you
make XML documents.

Anyway, from your perspective, the header is an indication but not a
foolproof way of figuring encoding out.

> My question was for a function that scan the bytes of the file and decided
> WITHOUT the BOM heading.
> I mean by checking the bytes sequence in the file.
>
> I claim that WITHOUT a BOM it might be impossible to assure it is UTF-8
> encoding which is a whole escape sequence logic
> that may convert one character into one, two or three character.

http://se.php.net/manual/en/function.mb-detect-encoding.php - the
first comment should be interesting to you.

*
If you try to use mb_detect_encoding to detect whether a string is
valid UTF-8, use the strict mode, it is pretty worthless otherwise.




Regards
Peter

-- 

WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Check the byte sequence of a file to tell if it is UTF-8 without the BOM using PHP ?

[Eli Orr (Office)]

Hi Adam,

I have a prof that the XML advise does not work in real cases I had.
We are using XMLs in our system but when you edit the XML with  a text 
editor and put the XML heading of UTF-8



it DOES NOT assure the text inside is encoded in UTF-8 so but maybe 
(many cases) t other iso-xxx method.


My question was for a function that scan the bytes of the file and 
decided WITHOUT the BOM heading.

I mean by checking the bytes sequence in the file.

I claim that WITHOUT a BOM it might be impossible to assure it is UTF-8 
encoding which is a whole escape sequence logic

that may convert one character into one, two or three character.

Any advise if I'm right on this or smart file scan function that makes it?

Eli
On 21/05/2011 20:03, Adam Richardson wrote:
On Sat, May 21, 2011 at 12:10 PM, Eli Orr (Office) 
mailto:eli@logodial.com>> wrote:



Dear PHP Gurus,

I have a debate on the following please let me know what is true /
false.

I'am using a PHP function *is_UTF_8_file ($file_name) *that I've
found as part of my PHP 5.3 installation.
This function checks if the file start with the 3 UTF-8 BOM bytes.

However another guy told me that there is way to detect if a file
is a UTF-8 without having the BOM at the file start.
To me it sounds impossible since if you do not have this
indication you have a stream of bytes that you can never tell 100%
if that is UTF-8 or else.

Who is rigt here ?
If there is a Magical function that can detect files without a BOM
if they are UTF-8 or not please share you knowledge if this
is not a "NULL" or impossible function as I thought.


Here's a great write-up I've got bookmarked (he points out Windows 
Notepad automatically determines the encoding):

http://codesnipers.com/?q=node/68

* If it's an XML file, the structure allows you determine the
  encoding.
* For other files, you can encode it as UTF-8 and look for
  improper encodings.


As far as a PHP function that already does this, I'm not aware of it, 
but you could make a system call to "file" if your on Linux, as it 
tries to automatically determine the encoding:

http://linux.die.net/man/1/file

Adam

--
Nephtali:  A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com



--
Best Regards,

*Eli Orr*
CTO & Founder
*LogoDial Ltd.*
M:+972-54-7379604
O:+972-74-703-2034
F: +972-77-3379604

Plaut 10, Rehovot, Israel
Email: _Eli.Orr@LogoDial.com_
Skype: _eliorr.com_

Re: [PHP] Closing Session (Revisited)

[Roger Riordan]

On Thu, 05 May 2011 08:28:53 -0400, sstap...@mnsi.net (Steve Staples) wrote:

>On Thu, 2011-05-05 at 21:41 +1000, Roger Riordan wrote:
>> 
>> I have developed a common engine which I use for several different websites. 
>> I had been
>> using PHP 5.2.? and IE6 (yes; I know!), and had been able to have multiple 
>> sessions open
>> at once, displaying the same or different websites, without them interfering 
>> with each
>> other. This was incredibly useful; I could be looking at, or even edit, 
>> different parts of
>> the same, or different, websites simultaneously without any problems.
>> 
>> But I recently had a hard disk crash and had to re-install all the system 
>> software. Now I
>> have PHP 5.3 and IE 8, and find that if I try to do this the various 
>> sessions interfere
>> with each other. From the above comment I gather that this is because IE 8 
>> combines all
>> the instances, whereas previously each instance was treated as a different 
>> user.
>> 
>> Is there any simple way to make IE 8 treat each instance as a new user, or 
>> should I switch
>> to Chrome and use the Incognito feature?
>> 
>> Roger Riordan AM
>> http://www.corybas.com/
>> 
>
>The Incognito feature wont give you the results you're looking for.
>>From my experience, the incognito window(s) and tab(s) share the same
>memory/cookie/session space, which is different from the main window...
>which means you will run into the same issue.
>
>Once you close all your incognito windows/tabs, you will release those
>cookies/sessions/memory space and if you open a new one afterwards, then
>you will be fine, but if one tabs stays open, no go :(
>
>Have you looked at the http://ca3.php.net/session_name function, and
>putting that into your site just after your session_start() ?  I believe
>that will fix your issues (as long as your session names are unique),
>but i am not 100% sure.
>
>Steve
>

Thank you for this suggestion. This has solved the more serious half of my 
problems; I can
easily generate a different session name for each website, so that the various 
websites
don't interfere with each other, but I have not been able to devise a way to 
differentiate
between multiple sessions of the same website.

For example, if I open one copy of a website as a visitor I am shown as 
Visitor, but if I
then open another window, and log in as Manager, then go back to the first 
window I am
shown as Manager (with appropriate privileges) there also.

The only way I can think of to overcome this would be to generate a new named 
session
every time I log in, and then to pass the session name as a parameter every 
time I load a
new page. Unfortunately my program is sufficiently complicated that this is 
effectively
impractical, as it would involve tracking down and modifying every point in the 
program at
which a new page can be launched.

It also has a theoretical disadvantage that if someone bookmarks a page they 
will book
mark the session name, but this can fairly readily be overcome.

Is there any alternative way in which a different session name (or equivalent 
flag) can be
attached to each instance of the browser?

(Effectively these problems only affect the developer, as they only apply to 
multiple
instances of the same browser on the same PC.)


PS. At this stage I devised a really nasty kludge, which enables me to run 
multiple copies
without them interfering. In my program new pages are always launched by a 
command of the
general type:

http://localhost/cypalda.com/index.php?level=1&item=22

This loads the file index.php, which is a very brief file in the public 
directory
(cypalda.com in this case). It sets a couple of constants and then transfers 
control to a
file Begin.php, in a private directory. This in turn sets up a whole lot more 
constants,
and then transfers control to the main program, which is common to 5 different 
websites.

I realised that if I specify the session name in index.php, I can make several 
copies of
this file, e.g. index.php, index1.php, index2.php, each of which specified a 
different
session name. I thought this still left me the problem of modifying all the 
points at
which a new page was launched, but then I found that by great good fortune (or 
foresight!)
I had defined a constant $home_page = index.php, and always launched a new page 
with the
basic command
echo ('http://www.corybas.com/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] A Review Request

[Robert Cummings]

On 11-05-21 09:26 AM, tedd wrote:

At 2:49 PM -0400 5/19/11, Joshua Kehn wrote:

On May 19, 2011, at 2:44 PM, Andre Polykanine wrote:


  Hello Alex,

  Two (stupid?) questions:
  1. Why PHP_SELF is better than SCRIPT_NAME?
  2. Why strcmp() is better than just comparing?

  --
  With best regards from Ukraine,
  Andre
  Skype: Francophile
  My blog: http://oire.org/menelion (mostly in Russian)
  Twitter: http://twitter.com/m_elensule
  Facebook: http://facebook.com/menelion


No idea about the first, and I've never used strcmp() before for an
equality check. If there is something I'm missing I would love to
know.

Regards,

-Josh


-Josh:

The function strcmp() simply evaluates two strings and reports back
-1, 0, or 1 depending upon their  alphabetical relationship.


And therein lies it's advantage over a a direct comparison. This feature 
makes it great for sorting callbacks since you can just return the 
result of strcmp().


Cheers,
Rob.
--
E-Mail Disclaimer: Information contained in this message and any
attached documents is considered confidential and legally protected.
This message is intended solely for the addressee(s). Disclosure,
copying, and distribution are prohibited unless authorized.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] A Review Request

[Alex]

Yep, and it comes in handy, especially in school, lol, in advanced algorithms 
and datastructures, I once submitted a project assignment that was 5 lines 
long, and instead of figuring out anagrams, strcmp was very helpful :)

Sent from my Verizon Wireless 4GLTE smartphone

- Reply message -
From: "tedd" 
To: "Joshua Kehn" , "PHP General" 

Subject: [PHP] A Review Request
Date: Sat, May 21, 2011 9:26 am


At 2:49 PM -0400 5/19/11, Joshua Kehn wrote:
>On May 19, 2011, at 2:44 PM, Andre Polykanine wrote:
>
>>  Hello Alex,
>>
>>  Two (stupid?) questions:
>>  1. Why PHP_SELF is better than SCRIPT_NAME?
>>  2. Why strcmp() is better than just comparing?
>>
>>  --
>>  With best regards from Ukraine,
>>  Andre
>>  Skype: Francophile
>>  My blog: http://oire.org/menelion (mostly in Russian)
>>  Twitter: http://twitter.com/m_elensule
>>  Facebook: http://facebook.com/menelion
>
>No idea about the first, and I've never used strcmp() before for an 
>equality check. If there is something I'm missing I would love to 
>know.
>
>Regards,
>
>-Josh

-Josh:

The function strcmp() simply evaluates two strings and reports back 
-1, 0, or 1 depending upon their  alphabetical relationship.


Cheers,

tedd


-- 
---
http://sperling.com/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Defensive Programming

[tedd]

Hi Gang:

A word about:

http://en.wikipedia.org/wiki/Defensive_programming

Anyone read the classic "CHAOS" by Gleick?

The story of Mandelbrot is an interesting one where (as I remember 
it, I could be wrong) he was hired to do find a "Defensive" solution 
to telephone equipment failure. That investigation lead to the 
unescapable conclusion that nothing is without chaos. In short, the 
harder you try, the harder it gets.


That doesn't mean you give up, but rather admitting the best you can 
do is never good enough.


Cheers,

tedd
--
---
http://sperling.com/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Script ID?

[tedd]

At 6:29 PM +0100 5/21/11, Stuart Dallas wrote:
On Sat, May 21, 2011 at 6:00 PM, Peter Lind 
<peter.e.l...@gmail.com> wrote:


-snip-


This was fun... we should do it again sometime! ;)


No, this wasn't fun.

As I said before, is email is a bad way to communicate. But I think 
we are better than the medium.


What say you guys?  xxxoooxxx

Cheers,

tedd

--
---
http://sperling.com/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Script ID?

[Adam Richardson]

On Sat, May 21, 2011 at 10:11 AM, tedd  wrote:

> Hi gang:
>
> Okay, so,what's the "best" (i.e., most secure) way for your script to
> identify itself *IF* you plan on using that information later, such as the
> value in an action attribute in a form?
>
> For example, I was using:
>
> $self = basename($_SERVER['SCRIPT_NAME']);
>
> 
>
> However, that was susceptible to XSS.
>
> http://www.mc2design.com/blog/php_self-safe-alternatives
>
> says a simple action="#" would work.
>
> But is there a better way?
>
> What would do you do solve this?
>
> Cheers,
>
> tedd
>

Tedd, I'm sorry for the confusion.

When I referenced that article, I was speaking to Alex as to why it wouldn't
be prudent for you to use PHP_SELF (as he had suggested to avoid an
additional function call) as opposed to what you were currently using,
basename($_SERVER['SCRIPT_FILENAME']).

My point, and the point of the article, was that PHP_SELF requires special
precautions. However, script_filename is not susceptible to this type of
attack, as it does not include data from the user:
http://php.about.com/od/learnphp/qt/_SERVER_PHP.htm

In fact, basename($_SERVER['SCRIPT_FILENAME']), and basename(__FILE__) were
two of the mitigation methods mentioned in the closing of the article.

Try it out on your
server:

PHP_SELF (dangerous)

$_SERVER['SCRIPT_FILENAME']

$_SERVER['REQUEST_URI'] (dangerous)

__FILE__

basename(__FILE__)

basename($_SERVER['SCRIPT_NAME'])


Try to enter the attack vector and you'll see PHP_SELF could be terrible,
but the basename option for script_filename and __FILE__ are immune.

Again, sorry for the confusion.

Adam

-- 
Nephtali:  A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com

Re: [PHP] Script ID?

[Stuart Dallas]

On Sat, May 21, 2011 at 6:00 PM, Peter Lind  wrote:

> On 21 May 2011 18:42, Stuart Dallas  wrote:
> > On Sat, May 21, 2011 at 5:33 PM, Peter Lind 
> wrote:
> >>
> >> On 21 May 2011 18:26, Stuart Dallas  wrote:
> >>
> >> *snip*
> >>
> >> > http://en.wikipedia.org/wiki/Defensive_programming
> >> > You do things your way and I'll do things my way. Best of luck to you.
> >>
> >> Thank you for your condescending tone. Best of luck to you too.
> >
> > It is regrettable if you took offence, but I stand by my tone. I've
> cleaned
> > up too many messes over the years that were caused by careless (and in
> some
> > cases incompetent) assumptions that I have little time for anyone who
> > doesn't see the value in expecting the unexpected.
>
> Yet you assume that I have no experience, have never cleaned up messes
> after others, and generally have no clue what I'm talking about. At no
> point did I state that I see no value in expecting the unexpected or
> that I disagree with defensive programming. What I did state is that I
> prefer clearing up any unclear areas and remove assumptions - if I end
> up spending most of my time doing defensive programming because I
> haven't cleared up the specifications with the client, then I have
> done a very poor job.
>

Any assumptions I made regarding your level of experience came from this
comment..

[I would personally go with "let's either find out or make a decision"
instead of wasting time on coding for situations that will crop up.]

Aside from the presumably erroneous use of "will" instead of "may", this
suggests to me that you are the type of developer who writes code in the
quickest way possible without any concern for its quality or its use beyond
your involvement. Maybe I'm wrong, but I can only go by the evidence that's
presented.

My primary point was that you have not removed assumptions. You may think
you have by putting restrictions on the environment in which your code runs,
but as I said earlier, the larger a project becomes the less likely it will
be that those conditions are going to remain in place. So, those
restrictions are essentially assumptions.

No piece of software would ever get finished without assumptions being made
or various restrictions being in place, but it's always a compromise between
cost of mitigation now against the cost of dealing with changes in the
future (the 10%/90% I mentioned earlier). On that basis I see huge value in
normalising and centralising the generation of URLs for any project that
consists of more than a few simple PHP pages.

Anyway, I doubt there's much point in continuing the conversation -
> you seem to have a set worldview and it appears that my role in it is
> the same regardless of what I state from here on out.
>

Your role in my world is simply that if your responses in this thread
reflect how you approach your software development, unless you say or do
something that changes my view of that approach I would probably avoid ever
working with you, or on any software with which you've been involved.

This was fun... we should do it again sometime! ;)

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

Re: [PHP] Script ID?

[Tamara Temple]

On May 21, 2011, at 9:11 AM, tedd wrote:


Hi gang:

Okay, so,what's the "best" (i.e., most secure) way for your script  
to identify itself *IF* you plan on using that information later,  
such as the value in an action attribute in a form?


For example, I was using:

$self = basename($_SERVER['SCRIPT_NAME']);



However, that was susceptible to XSS.

http://www.mc2design.com/blog/php_self-safe-alternatives

says a simple action="#" would work.

But is there a better way?

What would do you do solve this?

Cheers,

tedd


--
---
http://sperling.com/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Hi, everyone. I've been following this thread, and as I am not that  
familiar with XSS attacks, I went searching for information about  
them. I did find this:



https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

which may help others like me begin to understand the issue. That  
said, I really don't understand how using something like  
$self=basename($_SERVER['SCRIPT_NAME']); becomes vulnerable to an XSS  
attack. Can someone explain to me how this works? Then I might be able  
to understand how to prevent it.


Thanks.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Script ID?

[Stuart Dallas]

On Sat, May 21, 2011 at 5:33 PM, Peter Lind  wrote:

> On 21 May 2011 18:26, Stuart Dallas  wrote:
>
> *snip*
>
> > http://en.wikipedia.org/wiki/Defensive_programming
> > You do things your way and I'll do things my way. Best of luck to you.
>
> Thank you for your condescending tone. Best of luck to you too.


It is regrettable if you took offence, but I stand by my tone. I've cleaned
up too many messes over the years that were caused by careless (and in some
cases incompetent) assumptions that I have little time for anyone who
doesn't see the value in expecting the unexpected.

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

Re: [PHP] a Debate here - How can you check a if a file is a UTF-8 without the BOM using PHP ?

[Adam Richardson]

On Sat, May 21, 2011 at 12:10 PM, Eli Orr (Office) wrote:

>
> Dear PHP Gurus,
>
> I have a debate on the following please let me know what is true / false.
>
> I'am using a PHP function *is_UTF_8_file ($file_name) *that I've found as
> part of my PHP 5.3 installation.
> This function checks if the file start with the 3 UTF-8 BOM bytes.
>
> However another guy told me that there is way to detect if a file is a
> UTF-8 without having the BOM at the file start.
> To me it sounds impossible since if you do not have this indication you
> have a stream of bytes that you can never tell 100% if that is UTF-8 or
> else.
>
> Who is rigt here ?
> If there is a Magical function that can detect files without a BOM if they
> are UTF-8 or not please share you knowledge if this
> is not a "NULL" or impossible function as I thought.
>

Here's a great write-up I've got bookmarked (he points out Windows Notepad
automatically determines the encoding):
http://codesnipers.com/?q=node/68

   - If it's an XML file, the structure allows you determine the encoding.
   - For other files, you can encode it as UTF-8 and look for improper
   encodings.


As far as a PHP function that already does this, I'm not aware of it, but
you could make a system call to "file" if your on Linux, as it tries to
automatically determine the encoding:
http://linux.die.net/man/1/file

Adam

-- 
Nephtali:  A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com

Re: [PHP] Object Query Language optimization

[jean-baptiste verrey]

hi,

"I often use SQL that is far, far more complex than this."
well, this is why my OQL is pretty simple, it does not intend to do any
crazy stuff that you can do with SQL (as I can load objects from SQL as
well)

I had a look at other ORM, and the problem is that some are extremely
complicated (Doctrine is a very specialized framework, you can basically do
anything you can do with SQL but in OQL) , they don't have OQL, they use
active recode like query,  or they use a class with chain methods.

My problem in itself is not really a problem as it is working, but I just
wonder how to optimize it, if I should write some different version and
benchmark it, or identify from the beginning that my solution is good
enough.

Thanks anyway^^


On 21 May 2011 16:54, Mark Kelly  wrote:

> Hi.
>
> On Saturday 21 May 2011 at 15:56 jean-baptiste verrey wrote:
>
> > I'm writing an Object Query Language
>
> [snip]
>
> > (queries don't get much more complicated than that, you have multiple
> > alias.fieldName in the select, then multiple joins)
>
> I often use SQL that is far, far more complex than this.
>
> Anyway, I can't help directly with the code, other than to suggest that you
> take a look at other projects that do the same thing and see how they do
> it.
> There's a starter list at:
>
> http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#PHP
>
> HTH,
>
> Mark
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP] Script ID?

[Peter Lind]

On 21 May 2011 18:42, Stuart Dallas  wrote:
> On Sat, May 21, 2011 at 5:33 PM, Peter Lind  wrote:
>>
>> On 21 May 2011 18:26, Stuart Dallas  wrote:
>>
>> *snip*
>>
>> > http://en.wikipedia.org/wiki/Defensive_programming
>> > You do things your way and I'll do things my way. Best of luck to you.
>>
>> Thank you for your condescending tone. Best of luck to you too.
>
> It is regrettable if you took offence, but I stand by my tone. I've cleaned
> up too many messes over the years that were caused by careless (and in some
> cases incompetent) assumptions that I have little time for anyone who
> doesn't see the value in expecting the unexpected.

Yet you assume that I have no experience, have never cleaned up messes
after others, and generally have no clue what I'm talking about. At no
point did I state that I see no value in expecting the unexpected or
that I disagree with defensive programming. What I did state is that I
prefer clearing up any unclear areas and remove assumptions - if I end
up spending most of my time doing defensive programming because I
haven't cleared up the specifications with the client, then I have
done a very poor job.

Anyway, I doubt there's much point in continuing the conversation -
you seem to have a set worldview and it appears that my role in it is
the same regardless of what I state from here on out.

So: best of luck to you.

Regards
Peter

-- 

WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Script ID?

[Peter Lind]

On 21 May 2011 18:26, Stuart Dallas  wrote:

*snip*

> http://en.wikipedia.org/wiki/Defensive_programming
> You do things your way and I'll do things my way. Best of luck to you.

Thank you for your condescending tone. Best of luck to you too.

Regards
Peter

-- 

WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Script ID?

[Stuart Dallas]

On Sat, May 21, 2011 at 5:14 PM, Peter Lind  wrote:

> On 21 May 2011 18:05, Stuart Dallas  wrote:
> > On Sat, May 21, 2011 at 4:57 PM, Peter Lind 
> wrote:
> >>
> >> On 21 May 2011 17:34, Stuart Dallas  wrote:
> >> > On Sat, May 21, 2011 at 4:24 PM, Peter Lind 
> >> > wrote:
> >> >>
> >> >> On 21 May 2011 17:18, Stuart Dallas  wrote:
> >> >>
> >> >> *snip*
> >> >>
> >> >> >> Again, this depends upon what your url scheme looks like - and
> >> >> >> without
> >> >> >> knowing that, there's simple no clue as to whether or not this is
> a
> >> >> >> good solution to the problem (though it might be a good solution
> to
> >> >> >> A
> >> >> >> problem).
> >> >> >
> >> >> > Again, I disagree. If you have an example of a URL structure where
> >> >> > this
> >> >> > would not work I'd love to hear it.
> >> >> > -Stuart
> >> >>
> >> >> Having to replace several times just in order to figure out the path
> >> >> to your script is pointless if you know the name of the script (which
> >> >> you always do - it's __FILE__ ) and you're using a one-to-one
> >> >> request-to-script scheme. Then just grab the part of the url up to
> and
> >> >> including your scriptname.
> >> >
> >> > Well, it would be basename(__FILE__), but that's beside the point. In
> >> > this
> >> > particular case, where the PHP filename is the last part of the URL,
> >> > that
> >> > will indeed work. However, as you have pointed out several times
> that's
> >> > not
> >> > always the case and I tend to write generic, defensive code rather
> than
> >> > make
> >> > assumptions.
> >>
> >> Not a bad habit. I would personally go with "let's either find out or
> >> make a decision" instead of wasting time on coding for situations that
> >> will crop up.
> >
> > Assumptions cost money, and if you haven't discovered that yet then
> you've
> > either not been in the software development game very long or you've been
> > lucky so far. Hold on to that feeling, cos you can't get it back when
> it's
> > gone!
>
> Assumptions and knowledge are two different things. If you haven't
> discovered that yet then you've either not been in the software
> development game very long or you've been doing things wrong so far. I
> suggest spending some time checking up on the difference.


You can't know everything, and anything you do know is only true as of right
now.

You can't control the future and all predictions you make are based on
assumptions, and if/when your assumptions turn out to be wrong it will cost
money. Trust me on that.

http://en.wikipedia.org/wiki/Defensive_programming

You do things your way and I'll do things my way. Best of luck to you.

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

Re: [PHP] Script ID?

[Peter Lind]

On 21 May 2011 18:05, Stuart Dallas  wrote:
> On Sat, May 21, 2011 at 4:57 PM, Peter Lind  wrote:
>>
>> On 21 May 2011 17:34, Stuart Dallas  wrote:
>> > On Sat, May 21, 2011 at 4:24 PM, Peter Lind 
>> > wrote:
>> >>
>> >> On 21 May 2011 17:18, Stuart Dallas  wrote:
>> >>
>> >> *snip*
>> >>
>> >> >> Again, this depends upon what your url scheme looks like - and
>> >> >> without
>> >> >> knowing that, there's simple no clue as to whether or not this is a
>> >> >> good solution to the problem (though it might be a good solution to
>> >> >> A
>> >> >> problem).
>> >> >
>> >> > Again, I disagree. If you have an example of a URL structure where
>> >> > this
>> >> > would not work I'd love to hear it.
>> >> > -Stuart
>> >>
>> >> Having to replace several times just in order to figure out the path
>> >> to your script is pointless if you know the name of the script (which
>> >> you always do - it's __FILE__ ) and you're using a one-to-one
>> >> request-to-script scheme. Then just grab the part of the url up to and
>> >> including your scriptname.
>> >
>> > Well, it would be basename(__FILE__), but that's beside the point. In
>> > this
>> > particular case, where the PHP filename is the last part of the URL,
>> > that
>> > will indeed work. However, as you have pointed out several times that's
>> > not
>> > always the case and I tend to write generic, defensive code rather than
>> > make
>> > assumptions.
>>
>> Not a bad habit. I would personally go with "let's either find out or
>> make a decision" instead of wasting time on coding for situations that
>> will crop up.
>
> Assumptions cost money, and if you haven't discovered that yet then you've
> either not been in the software development game very long or you've been
> lucky so far. Hold on to that feeling, cos you can't get it back when it's
> gone!

Assumptions and knowledge are two different things. If you haven't
discovered that yet then you've either not been in the software
development game very long or you've been doing things wrong so far. I
suggest spending some time checking up on the difference.

Regards
Peter

-- 

WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] a Debate here - How can you check a if a file is a UTF-8 without the BOM using PHP ?

[Eli Orr (Office)]

Dear PHP Gurus,

I have a debate on the following please let me know what is true / false.

I'am using a PHP function *is_UTF_8_file ($file_name) *that I've found 
as part of my PHP 5.3 installation.

This function checks if the file start with the 3 UTF-8 BOM bytes.

However another guy told me that there is way to detect if a file is a 
UTF-8 without having the BOM at the file start.
To me it sounds impossible since if you do not have this indication you 
have a stream of bytes that you can never tell 100% if that is UTF-8 or 
else.


Who is rigt here ?
If there is a Magical function that can detect files without a BOM if 
they are UTF-8 or not please share you knowledge if this

is not a "NULL" or impossible function as I thought.

Many thanks for you wise advise.

--
Best Regards,

*Eli Orr*
*LogoDial Ltd.*
Email: _Eli.Orr@LogoDial.com_
Skype: _eliorr.com_

Re: [PHP] Script ID?

[Stuart Dallas]

On Sat, May 21, 2011 at 5:02 PM, Ashley Sheridan
wrote:

>  On Sat, 2011-05-21 at 16:53 +0100, Stuart Dallas wrote:
>
> On Sat, May 21, 2011 at 4:48 PM, Ashley Sheridan
> wrote:
>
> >  On Sat, 2011-05-21 at 16:47 +0100, Stuart Dallas wrote:
> >
> > On Sat, May 21, 2011 at 4:42 PM, Ashley Sheridan
> > wrote:
> >
> > >  On Sat, 2011-05-21 at 16:34 +0100, Stuart Dallas wrote:
> > >
> > > On Sat, May 21, 2011 at 4:24 PM, Peter Lind  
> > > wrote:
> > >
> > > > On 21 May 2011 17:18, Stuart Dallas  wrote:
> > > >
> > > > *snip*
> > > >
> > > > >> Again, this depends upon what your url scheme looks like - and 
> > > > >> without
> > > > >> knowing that, there's simple no clue as to whether or not this is a
> > > > >> good solution to the problem (though it might be a good solution to A
> > > > >> problem).
> > > > >
> > > > > Again, I disagree. If you have an example of a URL structure where 
> > > > > this
> > > > > would not work I'd love to hear it.
> > > > > -Stuart
> > > >
> > > > Having to replace several times just in order to figure out the path
> > > > to your script is pointless if you know the name of the script (which
> > > > you always do - it's __FILE__ ) and you're using a one-to-one
> > > > request-to-script scheme. Then just grab the part of the url up to and
> > > > including your scriptname.
> > > >
> > >
> > > Well, it would be basename(__FILE__), but that's beside the point. In this
> > > particular case, where the PHP filename is the last part of the URL, that
> > > will indeed work. However, as you have pointed out several times that's 
> > > not
> > > always the case and I tend to write generic, defensive code rather than 
> > > make
> > > assumptions.
> > >
> > > Note I used the word good - doing several str_replace() and other
> > > > calls is not what I consider a good solution if there's something
> > > > simpler available with as good a result.
> > >
> > >
> > > Obviously that's your choice to make, but these days I very rarely work on
> > > projects where there is a one-to-one mapping, and even if I did I would 
> > > not
> > > rely on that always being the case. I've worked on a number of projects
> > > where the URL structure has been massively changed (a couple from 
> > > one-to-one
> > > to controller-based) where it would have taking an excessive amount of 
> > > time
> > > to undo that assumption.
> > >
> > > Using rawurlencode on $_SERVER['REQUEST_URI'] is flexible, largely
> > > future-proof and takes no more effort than the manipulation you are doing 
> > > on
> > > __FILE__ to get the same result. Given the choice I'll always go for 10%
> > > extra work now to save 90% extra work later, even if it's only potential
> > > work later.
> > >
> > > -Stuart
> > >
> > >
> > >
> > >
> > > I'm not sure if anyone had the chance to look over my code suggestion, but
> > > afaict it does the job, although I've only given it very rudimentary
> > > testing. It doesn't require you to know the page the form is on in 
> > > advance,
> > > it strips out the correct info from the supplied URL, and is simple enough
> > > that you could even run it all on one line if you didn't mind nested
> > > tertiary conditionals.
> > >
> >
> > If 404 responses show a custom page containing a form that uses your code
> > then it's still an XSS risk, but other than that it looks safe. However,
> > based on that single risk (and there may be others) I'd never use it because
> > you never know when someone will change the server config.
> >
> > -Stuart
> >
> >
> >
> > What would the risk on the 404 page be? I must admit, I don't know a huge
> > amount about XSS attacks, so this one is new to me.
> >
>
> A similar URL to the one in the URL tedd posted 
> (http://www.mc2design.com/blog/php_self-safe-alternatives).
>
> Something like this...
> http://www.server.com/%22%3E%3Cscript%3Ealert('xss attack')%3C/script%3E
>
> That script code will not be seen as PATH_INFO, it will simply be part of
> the URL.
>
> -Stuart
>
>
>
> Ah, I see, but it shouldn't be too difficult to use some other variable in
> the $_SERVER array. Anyway, if you are displaying a form on a 404 error
> page, you won't want it to post to itself, as where is the processing going
> to be done? If you have a system that can process it, then it should be
> capable of ensuring the form posts back to a safe area, such as the home
> area of the site.
>

Any variable in the $_SERVER array that contains the current URL in some
form will likely suffer from the same issue.

The example I gave there was very simple. Imagine a site with a very dynamic
and complex URL structure and you can imagine a situation where this
vulnerability might crop up.

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

Re: [PHP] Script ID?

[Stuart Dallas]

On Sat, May 21, 2011 at 4:57 PM, Peter Lind  wrote:

> On 21 May 2011 17:34, Stuart Dallas  wrote:
> > On Sat, May 21, 2011 at 4:24 PM, Peter Lind 
> wrote:
> >>
> >> On 21 May 2011 17:18, Stuart Dallas  wrote:
> >>
> >> *snip*
> >>
> >> >> Again, this depends upon what your url scheme looks like - and
> without
> >> >> knowing that, there's simple no clue as to whether or not this is a
> >> >> good solution to the problem (though it might be a good solution to A
> >> >> problem).
> >> >
> >> > Again, I disagree. If you have an example of a URL structure where
> this
> >> > would not work I'd love to hear it.
> >> > -Stuart
> >>
> >> Having to replace several times just in order to figure out the path
> >> to your script is pointless if you know the name of the script (which
> >> you always do - it's __FILE__ ) and you're using a one-to-one
> >> request-to-script scheme. Then just grab the part of the url up to and
> >> including your scriptname.
> >
> > Well, it would be basename(__FILE__), but that's beside the point. In
> this
> > particular case, where the PHP filename is the last part of the URL, that
> > will indeed work. However, as you have pointed out several times that's
> not
> > always the case and I tend to write generic, defensive code rather than
> make
> > assumptions.
>
> Not a bad habit. I would personally go with "let's either find out or
> make a decision" instead of wasting time on coding for situations that
> will crop up.
>

Assumptions cost money, and if you haven't discovered that yet then you've
either not been in the software development game very long or you've been
lucky so far. Hold on to that feeling, cos you can't get it back when it's
gone!

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

Re: [PHP] Script ID?

[Ashley Sheridan]

On Sat, 2011-05-21 at 16:53 +0100, Stuart Dallas wrote:

> On Sat, May 21, 2011 at 4:48 PM, Ashley Sheridan
> wrote:
> 
> >  On Sat, 2011-05-21 at 16:47 +0100, Stuart Dallas wrote:
> >
> > On Sat, May 21, 2011 at 4:42 PM, Ashley Sheridan
> > wrote:
> >
> > >  On Sat, 2011-05-21 at 16:34 +0100, Stuart Dallas wrote:
> > >
> > > On Sat, May 21, 2011 at 4:24 PM, Peter Lind  
> > > wrote:
> > >
> > > > On 21 May 2011 17:18, Stuart Dallas  wrote:
> > > >
> > > > *snip*
> > > >
> > > > >> Again, this depends upon what your url scheme looks like - and 
> > > > >> without
> > > > >> knowing that, there's simple no clue as to whether or not this is a
> > > > >> good solution to the problem (though it might be a good solution to A
> > > > >> problem).
> > > > >
> > > > > Again, I disagree. If you have an example of a URL structure where 
> > > > > this
> > > > > would not work I'd love to hear it.
> > > > > -Stuart
> > > >
> > > > Having to replace several times just in order to figure out the path
> > > > to your script is pointless if you know the name of the script (which
> > > > you always do - it's __FILE__ ) and you're using a one-to-one
> > > > request-to-script scheme. Then just grab the part of the url up to and
> > > > including your scriptname.
> > > >
> > >
> > > Well, it would be basename(__FILE__), but that's beside the point. In this
> > > particular case, where the PHP filename is the last part of the URL, that
> > > will indeed work. However, as you have pointed out several times that's 
> > > not
> > > always the case and I tend to write generic, defensive code rather than 
> > > make
> > > assumptions.
> > >
> > > Note I used the word good - doing several str_replace() and other
> > > > calls is not what I consider a good solution if there's something
> > > > simpler available with as good a result.
> > >
> > >
> > > Obviously that's your choice to make, but these days I very rarely work on
> > > projects where there is a one-to-one mapping, and even if I did I would 
> > > not
> > > rely on that always being the case. I've worked on a number of projects
> > > where the URL structure has been massively changed (a couple from 
> > > one-to-one
> > > to controller-based) where it would have taking an excessive amount of 
> > > time
> > > to undo that assumption.
> > >
> > > Using rawurlencode on $_SERVER['REQUEST_URI'] is flexible, largely
> > > future-proof and takes no more effort than the manipulation you are doing 
> > > on
> > > __FILE__ to get the same result. Given the choice I'll always go for 10%
> > > extra work now to save 90% extra work later, even if it's only potential
> > > work later.
> > >
> > > -Stuart
> > >
> > >
> > >
> > >
> > > I'm not sure if anyone had the chance to look over my code suggestion, but
> > > afaict it does the job, although I've only given it very rudimentary
> > > testing. It doesn't require you to know the page the form is on in 
> > > advance,
> > > it strips out the correct info from the supplied URL, and is simple enough
> > > that you could even run it all on one line if you didn't mind nested
> > > tertiary conditionals.
> > >
> >
> > If 404 responses show a custom page containing a form that uses your code
> > then it's still an XSS risk, but other than that it looks safe. However,
> > based on that single risk (and there may be others) I'd never use it because
> > you never know when someone will change the server config.
> >
> > -Stuart
> >
> >
> >
> > What would the risk on the 404 page be? I must admit, I don't know a huge
> > amount about XSS attacks, so this one is new to me.
> >
> 
> A similar URL to the one in the URL tedd posted (
> http://www.mc2design.com/blog/php_self-safe-alternatives).
> 
> Something like this...
> 
> http://www.server.com/%22%3E%3Cscript%3Ealert('xss attack')%3C/script%3E
> 
> That script code will not be seen as PATH_INFO, it will simply be part of
> the URL.
> 
> -Stuart
> 


Ah, I see, but it shouldn't be too difficult to use some other variable
in the $_SERVER array. Anyway, if you are displaying a form on a 404
error page, you won't want it to post to itself, as where is the
processing going to be done? If you have a system that can process it,
then it should be capable of ensuring the form posts back to a safe
area, such as the home area of the site.

-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] Script ID?

[Peter Lind]

On 21 May 2011 17:34, Stuart Dallas  wrote:
> On Sat, May 21, 2011 at 4:24 PM, Peter Lind  wrote:
>>
>> On 21 May 2011 17:18, Stuart Dallas  wrote:
>>
>> *snip*
>>
>> >> Again, this depends upon what your url scheme looks like - and without
>> >> knowing that, there's simple no clue as to whether or not this is a
>> >> good solution to the problem (though it might be a good solution to A
>> >> problem).
>> >
>> > Again, I disagree. If you have an example of a URL structure where this
>> > would not work I'd love to hear it.
>> > -Stuart
>>
>> Having to replace several times just in order to figure out the path
>> to your script is pointless if you know the name of the script (which
>> you always do - it's __FILE__ ) and you're using a one-to-one
>> request-to-script scheme. Then just grab the part of the url up to and
>> including your scriptname.
>
> Well, it would be basename(__FILE__), but that's beside the point. In this
> particular case, where the PHP filename is the last part of the URL, that
> will indeed work. However, as you have pointed out several times that's not
> always the case and I tend to write generic, defensive code rather than make
> assumptions.

Not a bad habit. I would personally go with "let's either find out or
make a decision" instead of wasting time on coding for situations that
will crop up.

>>
>> Note I used the word good - doing several str_replace() and other
>> calls is not what I consider a good solution if there's something
>> simpler available with as good a result.
>
> Obviously that's your choice to make, but these days I very rarely work on
> projects where there is a one-to-one mapping, and even if I did I would not
> rely on that always being the case. I've worked on a number of projects
> where the URL structure has been massively changed (a couple from one-to-one
> to controller-based) where it would have taking an excessive amount of time
> to undo that assumption.
> Using rawurlencode on $_SERVER['REQUEST_URI'] is flexible, largely
> future-proof and takes no more effort than the manipulation you are doing on
> __FILE__ to get the same result. Given the choice I'll always go for 10%
> extra work now to save 90% extra work later, even if it's only potential
> work later.

I can generally agree with that, depending on project though.

Regards
Peter

-- 

WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Object Query Language optimization

[Mark Kelly]

Hi.

On Saturday 21 May 2011 at 15:56 jean-baptiste verrey wrote:

> I'm writing an Object Query Language 

[snip]

> (queries don't get much more complicated than that, you have multiple
> alias.fieldName in the select, then multiple joins)

I often use SQL that is far, far more complex than this.

Anyway, I can't help directly with the code, other than to suggest that you 
take a look at other projects that do the same thing and see how they do it. 
There's a starter list at:

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#PHP

HTH,

Mark

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Script ID?

[Stuart Dallas]

On Sat, May 21, 2011 at 4:48 PM, Ashley Sheridan
wrote:

>  On Sat, 2011-05-21 at 16:47 +0100, Stuart Dallas wrote:
>
> On Sat, May 21, 2011 at 4:42 PM, Ashley Sheridan
> wrote:
>
> >  On Sat, 2011-05-21 at 16:34 +0100, Stuart Dallas wrote:
> >
> > On Sat, May 21, 2011 at 4:24 PM, Peter Lind  wrote:
> >
> > > On 21 May 2011 17:18, Stuart Dallas  wrote:
> > >
> > > *snip*
> > >
> > > >> Again, this depends upon what your url scheme looks like - and without
> > > >> knowing that, there's simple no clue as to whether or not this is a
> > > >> good solution to the problem (though it might be a good solution to A
> > > >> problem).
> > > >
> > > > Again, I disagree. If you have an example of a URL structure where this
> > > > would not work I'd love to hear it.
> > > > -Stuart
> > >
> > > Having to replace several times just in order to figure out the path
> > > to your script is pointless if you know the name of the script (which
> > > you always do - it's __FILE__ ) and you're using a one-to-one
> > > request-to-script scheme. Then just grab the part of the url up to and
> > > including your scriptname.
> > >
> >
> > Well, it would be basename(__FILE__), but that's beside the point. In this
> > particular case, where the PHP filename is the last part of the URL, that
> > will indeed work. However, as you have pointed out several times that's not
> > always the case and I tend to write generic, defensive code rather than make
> > assumptions.
> >
> > Note I used the word good - doing several str_replace() and other
> > > calls is not what I consider a good solution if there's something
> > > simpler available with as good a result.
> >
> >
> > Obviously that's your choice to make, but these days I very rarely work on
> > projects where there is a one-to-one mapping, and even if I did I would not
> > rely on that always being the case. I've worked on a number of projects
> > where the URL structure has been massively changed (a couple from one-to-one
> > to controller-based) where it would have taking an excessive amount of time
> > to undo that assumption.
> >
> > Using rawurlencode on $_SERVER['REQUEST_URI'] is flexible, largely
> > future-proof and takes no more effort than the manipulation you are doing on
> > __FILE__ to get the same result. Given the choice I'll always go for 10%
> > extra work now to save 90% extra work later, even if it's only potential
> > work later.
> >
> > -Stuart
> >
> >
> >
> >
> > I'm not sure if anyone had the chance to look over my code suggestion, but
> > afaict it does the job, although I've only given it very rudimentary
> > testing. It doesn't require you to know the page the form is on in advance,
> > it strips out the correct info from the supplied URL, and is simple enough
> > that you could even run it all on one line if you didn't mind nested
> > tertiary conditionals.
> >
>
> If 404 responses show a custom page containing a form that uses your code
> then it's still an XSS risk, but other than that it looks safe. However,
> based on that single risk (and there may be others) I'd never use it because
> you never know when someone will change the server config.
>
> -Stuart
>
>
>
> What would the risk on the 404 page be? I must admit, I don't know a huge
> amount about XSS attacks, so this one is new to me.
>

A similar URL to the one in the URL tedd posted (
http://www.mc2design.com/blog/php_self-safe-alternatives).

Something like this...

http://www.server.com/%22%3E%3Cscript%3Ealert('xss attack')%3C/script%3E

That script code will not be seen as PATH_INFO, it will simply be part of
the URL.

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

Re: [PHP] Script ID?

[Ashley Sheridan]

On Sat, 2011-05-21 at 16:47 +0100, Stuart Dallas wrote:

> On Sat, May 21, 2011 at 4:42 PM, Ashley Sheridan
> wrote:
> 
> >  On Sat, 2011-05-21 at 16:34 +0100, Stuart Dallas wrote:
> >
> > On Sat, May 21, 2011 at 4:24 PM, Peter Lind  wrote:
> >
> > > On 21 May 2011 17:18, Stuart Dallas  wrote:
> > >
> > > *snip*
> > >
> > > >> Again, this depends upon what your url scheme looks like - and without
> > > >> knowing that, there's simple no clue as to whether or not this is a
> > > >> good solution to the problem (though it might be a good solution to A
> > > >> problem).
> > > >
> > > > Again, I disagree. If you have an example of a URL structure where this
> > > > would not work I'd love to hear it.
> > > > -Stuart
> > >
> > > Having to replace several times just in order to figure out the path
> > > to your script is pointless if you know the name of the script (which
> > > you always do - it's __FILE__ ) and you're using a one-to-one
> > > request-to-script scheme. Then just grab the part of the url up to and
> > > including your scriptname.
> > >
> >
> > Well, it would be basename(__FILE__), but that's beside the point. In this
> > particular case, where the PHP filename is the last part of the URL, that
> > will indeed work. However, as you have pointed out several times that's not
> > always the case and I tend to write generic, defensive code rather than make
> > assumptions.
> >
> > Note I used the word good - doing several str_replace() and other
> > > calls is not what I consider a good solution if there's something
> > > simpler available with as good a result.
> >
> >
> > Obviously that's your choice to make, but these days I very rarely work on
> > projects where there is a one-to-one mapping, and even if I did I would not
> > rely on that always being the case. I've worked on a number of projects
> > where the URL structure has been massively changed (a couple from one-to-one
> > to controller-based) where it would have taking an excessive amount of time
> > to undo that assumption.
> >
> > Using rawurlencode on $_SERVER['REQUEST_URI'] is flexible, largely
> > future-proof and takes no more effort than the manipulation you are doing on
> > __FILE__ to get the same result. Given the choice I'll always go for 10%
> > extra work now to save 90% extra work later, even if it's only potential
> > work later.
> >
> > -Stuart
> >
> >
> >
> >
> > I'm not sure if anyone had the chance to look over my code suggestion, but
> > afaict it does the job, although I've only given it very rudimentary
> > testing. It doesn't require you to know the page the form is on in advance,
> > it strips out the correct info from the supplied URL, and is simple enough
> > that you could even run it all on one line if you didn't mind nested
> > tertiary conditionals.
> >
> 
> If 404 responses show a custom page containing a form that uses your code
> then it's still an XSS risk, but other than that it looks safe. However,
> based on that single risk (and there may be others) I'd never use it because
> you never know when someone will change the server config.
> 
> -Stuart
> 


What would the risk on the 404 page be? I must admit, I don't know a
huge amount about XSS attacks, so this one is new to me.

-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] Script ID?

[Stuart Dallas]

On Sat, May 21, 2011 at 4:42 PM, Ashley Sheridan
wrote:

>  On Sat, 2011-05-21 at 16:34 +0100, Stuart Dallas wrote:
>
> On Sat, May 21, 2011 at 4:24 PM, Peter Lind  wrote:
>
> > On 21 May 2011 17:18, Stuart Dallas  wrote:
> >
> > *snip*
> >
> > >> Again, this depends upon what your url scheme looks like - and without
> > >> knowing that, there's simple no clue as to whether or not this is a
> > >> good solution to the problem (though it might be a good solution to A
> > >> problem).
> > >
> > > Again, I disagree. If you have an example of a URL structure where this
> > > would not work I'd love to hear it.
> > > -Stuart
> >
> > Having to replace several times just in order to figure out the path
> > to your script is pointless if you know the name of the script (which
> > you always do - it's __FILE__ ) and you're using a one-to-one
> > request-to-script scheme. Then just grab the part of the url up to and
> > including your scriptname.
> >
>
> Well, it would be basename(__FILE__), but that's beside the point. In this
> particular case, where the PHP filename is the last part of the URL, that
> will indeed work. However, as you have pointed out several times that's not
> always the case and I tend to write generic, defensive code rather than make
> assumptions.
>
> Note I used the word good - doing several str_replace() and other
> > calls is not what I consider a good solution if there's something
> > simpler available with as good a result.
>
>
> Obviously that's your choice to make, but these days I very rarely work on
> projects where there is a one-to-one mapping, and even if I did I would not
> rely on that always being the case. I've worked on a number of projects
> where the URL structure has been massively changed (a couple from one-to-one
> to controller-based) where it would have taking an excessive amount of time
> to undo that assumption.
>
> Using rawurlencode on $_SERVER['REQUEST_URI'] is flexible, largely
> future-proof and takes no more effort than the manipulation you are doing on
> __FILE__ to get the same result. Given the choice I'll always go for 10%
> extra work now to save 90% extra work later, even if it's only potential
> work later.
>
> -Stuart
>
>
>
>
> I'm not sure if anyone had the chance to look over my code suggestion, but
> afaict it does the job, although I've only given it very rudimentary
> testing. It doesn't require you to know the page the form is on in advance,
> it strips out the correct info from the supplied URL, and is simple enough
> that you could even run it all on one line if you didn't mind nested
> tertiary conditionals.
>

If 404 responses show a custom page containing a form that uses your code
then it's still an XSS risk, but other than that it looks safe. However,
based on that single risk (and there may be others) I'd never use it because
you never know when someone will change the server config.

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

Re: [PHP] Script ID?

[Ashley Sheridan]

On Sat, 2011-05-21 at 16:34 +0100, Stuart Dallas wrote:

> On Sat, May 21, 2011 at 4:24 PM, Peter Lind  wrote:
> 
> > On 21 May 2011 17:18, Stuart Dallas  wrote:
> >
> > *snip*
> >
> > >> Again, this depends upon what your url scheme looks like - and without
> > >> knowing that, there's simple no clue as to whether or not this is a
> > >> good solution to the problem (though it might be a good solution to A
> > >> problem).
> > >
> > > Again, I disagree. If you have an example of a URL structure where this
> > > would not work I'd love to hear it.
> > > -Stuart
> >
> > Having to replace several times just in order to figure out the path
> > to your script is pointless if you know the name of the script (which
> > you always do - it's __FILE__ ) and you're using a one-to-one
> > request-to-script scheme. Then just grab the part of the url up to and
> > including your scriptname.
> >
> 
> Well, it would be basename(__FILE__), but that's beside the point. In this
> particular case, where the PHP filename is the last part of the URL, that
> will indeed work. However, as you have pointed out several times that's not
> always the case and I tend to write generic, defensive code rather than make
> assumptions.
> 
> Note I used the word good - doing several str_replace() and other
> > calls is not what I consider a good solution if there's something
> > simpler available with as good a result.
> 
> 
> Obviously that's your choice to make, but these days I very rarely work on
> projects where there is a one-to-one mapping, and even if I did I would not
> rely on that always being the case. I've worked on a number of projects
> where the URL structure has been massively changed (a couple from one-to-one
> to controller-based) where it would have taking an excessive amount of time
> to undo that assumption.
> 
> Using rawurlencode on $_SERVER['REQUEST_URI'] is flexible, largely
> future-proof and takes no more effort than the manipulation you are doing on
> __FILE__ to get the same result. Given the choice I'll always go for 10%
> extra work now to save 90% extra work later, even if it's only potential
> work later.
> 
> -Stuart
> 



I'm not sure if anyone had the chance to look over my code suggestion,
but afaict it does the job, although I've only given it very rudimentary
testing. It doesn't require you to know the page the form is on in
advance, it strips out the correct info from the supplied URL, and is
simple enough that you could even run it all on one line if you didn't
mind nested tertiary conditionals.

-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk

Re: [PHP] Script ID?

[Stuart Dallas]

On Sat, May 21, 2011 at 4:24 PM, Peter Lind  wrote:

> On 21 May 2011 17:18, Stuart Dallas  wrote:
>
> *snip*
>
> >> Again, this depends upon what your url scheme looks like - and without
> >> knowing that, there's simple no clue as to whether or not this is a
> >> good solution to the problem (though it might be a good solution to A
> >> problem).
> >
> > Again, I disagree. If you have an example of a URL structure where this
> > would not work I'd love to hear it.
> > -Stuart
>
> Having to replace several times just in order to figure out the path
> to your script is pointless if you know the name of the script (which
> you always do - it's __FILE__ ) and you're using a one-to-one
> request-to-script scheme. Then just grab the part of the url up to and
> including your scriptname.
>

Well, it would be basename(__FILE__), but that's beside the point. In this
particular case, where the PHP filename is the last part of the URL, that
will indeed work. However, as you have pointed out several times that's not
always the case and I tend to write generic, defensive code rather than make
assumptions.

Note I used the word good - doing several str_replace() and other
> calls is not what I consider a good solution if there's something
> simpler available with as good a result.


Obviously that's your choice to make, but these days I very rarely work on
projects where there is a one-to-one mapping, and even if I did I would not
rely on that always being the case. I've worked on a number of projects
where the URL structure has been massively changed (a couple from one-to-one
to controller-based) where it would have taking an excessive amount of time
to undo that assumption.

Using rawurlencode on $_SERVER['REQUEST_URI'] is flexible, largely
future-proof and takes no more effort than the manipulation you are doing on
__FILE__ to get the same result. Given the choice I'll always go for 10%
extra work now to save 90% extra work later, even if it's only potential
work later.

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

Re: [PHP] Script ID?

[Peter Lind]

On 21 May 2011 17:18, Stuart Dallas  wrote:

*snip*

>> Again, this depends upon what your url scheme looks like - and without
>> knowing that, there's simple no clue as to whether or not this is a
>> good solution to the problem (though it might be a good solution to A
>> problem).
>
> Again, I disagree. If you have an example of a URL structure where this
> would not work I'd love to hear it.
> -Stuart

Having to replace several times just in order to figure out the path
to your script is pointless if you know the name of the script (which
you always do - it's __FILE__ ) and you're using a one-to-one
request-to-script scheme. Then just grab the part of the url up to and
including your scriptname.

Note I used the word good - doing several str_replace() and other
calls is not what I consider a good solution if there's something
simpler available with as good a result.

Regards
Peter

-- 

WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Script ID?

[Stuart Dallas]

On Sat, May 21, 2011 at 4:07 PM, Peter Lind  wrote:

> On 21 May 2011 17:01, Stuart Dallas  wrote:
> > On Sat, May 21, 2011 at 3:35 PM, Peter Lind 
> wrote:
> >>
> >> On 21 May 2011 16:18, Stuart Dallas  wrote:
> >> > On Sat, May 21, 2011 at 3:11 PM, tedd  wrote:
> >> >
> >> >> Hi gang:
> >> >>
> >> >> Okay, so,what's the "best" (i.e., most secure) way for your script to
> >> >> identify itself *IF* you plan on using that information later, such
> as
> >> >> the
> >> >> value in an action attribute in a form?
> >> >>
> >> >> For example, I was using:
> >> >>
> >> >> $self = basename($_SERVER['SCRIPT_NAME']);
> >> >>
> >> >> 
> >> >>
> >> >> However, that was susceptible to XSS.
> >> >>
> >> >> http://www.mc2design.com/blog/php_self-safe-alternatives
> >> >>
> >> >> says a simple action="#" would work.
> >> >>
> >> >> But is there a better way?
> >> >>
> >> >> What would do you do solve this?
> >> >>
> >> >
> >> > If you want the form to submit to the same URL that generated the
> form,
> >> > I'd
> >> > recommend using $_SERVER['REQUEST_URI']. You can also omit the action
> >> > attribute entirely which, in my experience, will cause the browser to
> >> > submit
> >> > to the current URL. I have no idea whether that's part of the HTML
> spec,
> >> > but
> >> > that's the behaviour I've always observed.
> >>
> >> REQUEST_URI is as susceptible to XSS as the others. Omitting url
> >> entirely (in case of posting a form, say) works in most browsers but
> >> is known to fail in others (atm I can't recall which but Google should
> >> know). Both '?' and '#' will generally work, but are prone to problems
> >> with the base element.
> >
> > Yup, should have said that anything you use should be escaped.
> >>
> >> > Alternatively, by my reckoning, you could make your use of PHP_SELF
> safe
> >> > by
> >> > applying rawurlencode to $self when you put it in the action, but
> that's
> >> > only after 30 seconds of thinking about it.
> >>
> >> rawurlencode encodes forward slashes (and many other things). Not what
> >> you're looking for.
> >
> > Note that I said "your use," and tedd is running basename on the PHP_SELF
> > variable before using it so the escaping of forward slashes is not an
> issue
> > here hence why I didn't mention it.
> >>
> >> Apart from that, there is no single solution to the issue: if you're
> >> doing url rewrites, then you could use your route-to-url function
> >> instead of relying on any server variables. If your script is called
> >> directly instead, then use the part of the request uri up till and
> >> including the match for __FILE__.
> >
> > There is a single solution... know what URL you should be using at any
> given
> > point without making it depend on user(/browser)-supplied data. If you
> don't
> > know what URL you should be using at any given point, your architecture
> is
> > fundamentally flawed, whether than means passing it into shared code from
> > elsewhere, or using a single block of code to generate your URLs. In my
> > opinion you should never be generating URLs based on the URL that was
> used
> > to request the page.
>
> That is not a single solution - that is a general approach, for which
> the solution will look different based on whether or not you use url
> rewriting, actual script filenames, etc. etc. The point wasn't that
> there are no solutions, just that the solution to Tedd's problem
> depends upon how he's doing PHP in general.
>

I disagree, but I think it's more semantics than substance. By taking the
general approach of knowing what URLs you should be using everywhere in your
site without needing to take hints from the current URL, the problem goes
away... ergo it's a "solution".

The way you know what URLs you need at any given point may look slightly
different (whether you hard-code them or use a central function to generate
them), but the "general approach" is a "solution" to the problem of XSS
coming from the use of derived URLs.

> If you must generate it using that source, rawurlencode is still the way
> to
> > go. To get around the forward slash issue, replace all / with ~~~ (or
> > similar text that won't be modified by rawurlencode), run rawurlencode
> then
> > replace ~~~ with /. Wrap that up in a nice little function, and apply
> > liberally.
>
> Again, this depends upon what your url scheme looks like - and without
> knowing that, there's simple no clue as to whether or not this is a
> good solution to the problem (though it might be a good solution to A
> problem).


Again, I disagree. If you have an example of a URL structure where this
would not work I'd love to hear it.

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

[PHP] Re: Script ID?

[Al]

On 5/21/2011 10:11 AM, tedd wrote:

Hi gang:

Okay, so,what's the "best" (i.e., most secure) way for your script to identify
itself *IF* you plan on using that information later, such as the value in an
action attribute in a form?

For example, I was using:

$self = basename($_SERVER['SCRIPT_NAME']);



However, that was susceptible to XSS.

http://www.mc2design.com/blog/php_self-safe-alternatives

says a simple action="#" would work.

But is there a better way?

What would do you do solve this?

Cheers,

tedd




Consider saving a hash for your script file in a session buffer.

Then compare the hash value for the new file.

Or, just save the file's create date as a session value and compare it with the 
new one.


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Script ID?

[Peter Lind]

On 21 May 2011 17:01, Stuart Dallas  wrote:
> On Sat, May 21, 2011 at 3:35 PM, Peter Lind  wrote:
>>
>> On 21 May 2011 16:18, Stuart Dallas  wrote:
>> > On Sat, May 21, 2011 at 3:11 PM, tedd  wrote:
>> >
>> >> Hi gang:
>> >>
>> >> Okay, so,what's the "best" (i.e., most secure) way for your script to
>> >> identify itself *IF* you plan on using that information later, such as
>> >> the
>> >> value in an action attribute in a form?
>> >>
>> >> For example, I was using:
>> >>
>> >> $self = basename($_SERVER['SCRIPT_NAME']);
>> >>
>> >> 
>> >>
>> >> However, that was susceptible to XSS.
>> >>
>> >> http://www.mc2design.com/blog/php_self-safe-alternatives
>> >>
>> >> says a simple action="#" would work.
>> >>
>> >> But is there a better way?
>> >>
>> >> What would do you do solve this?
>> >>
>> >
>> > If you want the form to submit to the same URL that generated the form,
>> > I'd
>> > recommend using $_SERVER['REQUEST_URI']. You can also omit the action
>> > attribute entirely which, in my experience, will cause the browser to
>> > submit
>> > to the current URL. I have no idea whether that's part of the HTML spec,
>> > but
>> > that's the behaviour I've always observed.
>>
>> REQUEST_URI is as susceptible to XSS as the others. Omitting url
>> entirely (in case of posting a form, say) works in most browsers but
>> is known to fail in others (atm I can't recall which but Google should
>> know). Both '?' and '#' will generally work, but are prone to problems
>> with the base element.
>
> Yup, should have said that anything you use should be escaped.
>>
>> > Alternatively, by my reckoning, you could make your use of PHP_SELF safe
>> > by
>> > applying rawurlencode to $self when you put it in the action, but that's
>> > only after 30 seconds of thinking about it.
>>
>> rawurlencode encodes forward slashes (and many other things). Not what
>> you're looking for.
>
> Note that I said "your use," and tedd is running basename on the PHP_SELF
> variable before using it so the escaping of forward slashes is not an issue
> here hence why I didn't mention it.
>>
>> Apart from that, there is no single solution to the issue: if you're
>> doing url rewrites, then you could use your route-to-url function
>> instead of relying on any server variables. If your script is called
>> directly instead, then use the part of the request uri up till and
>> including the match for __FILE__.
>
> There is a single solution... know what URL you should be using at any given
> point without making it depend on user(/browser)-supplied data. If you don't
> know what URL you should be using at any given point, your architecture is
> fundamentally flawed, whether than means passing it into shared code from
> elsewhere, or using a single block of code to generate your URLs. In my
> opinion you should never be generating URLs based on the URL that was used
> to request the page.

That is not a single solution - that is a general approach, for which
the solution will look different based on whether or not you use url
rewriting, actual script filenames, etc. etc. The point wasn't that
there are no solutions, just that the solution to Tedd's problem
depends upon how he's doing PHP in general.

> If you must generate it using that source, rawurlencode is still the way to
> go. To get around the forward slash issue, replace all / with ~~~ (or
> similar text that won't be modified by rawurlencode), run rawurlencode then
> replace ~~~ with /. Wrap that up in a nice little function, and apply
> liberally.

Again, this depends upon what your url scheme looks like - and without
knowing that, there's simple no clue as to whether or not this is a
good solution to the problem (though it might be a good solution to A
problem).

Regards
Peter

-- 

WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Script ID?

[Stuart Dallas]

On Sat, May 21, 2011 at 3:35 PM, Peter Lind  wrote:

> On 21 May 2011 16:18, Stuart Dallas  wrote:
> > On Sat, May 21, 2011 at 3:11 PM, tedd  wrote:
> >
> >> Hi gang:
> >>
> >> Okay, so,what's the "best" (i.e., most secure) way for your script to
> >> identify itself *IF* you plan on using that information later, such as
> the
> >> value in an action attribute in a form?
> >>
> >> For example, I was using:
> >>
> >> $self = basename($_SERVER['SCRIPT_NAME']);
> >>
> >> 
> >>
> >> However, that was susceptible to XSS.
> >>
> >> http://www.mc2design.com/blog/php_self-safe-alternatives
> >>
> >> says a simple action="#" would work.
> >>
> >> But is there a better way?
> >>
> >> What would do you do solve this?
> >>
> >
> > If you want the form to submit to the same URL that generated the form,
> I'd
> > recommend using $_SERVER['REQUEST_URI']. You can also omit the action
> > attribute entirely which, in my experience, will cause the browser to
> submit
> > to the current URL. I have no idea whether that's part of the HTML spec,
> but
> > that's the behaviour I've always observed.
>
> REQUEST_URI is as susceptible to XSS as the others. Omitting url
> entirely (in case of posting a form, say) works in most browsers but
> is known to fail in others (atm I can't recall which but Google should
> know). Both '?' and '#' will generally work, but are prone to problems
> with the base element.
>

Yup, should have said that anything you use should be escaped.

> Alternatively, by my reckoning, you could make your use of PHP_SELF safe
> by
> > applying rawurlencode to $self when you put it in the action, but that's
> > only after 30 seconds of thinking about it.
>
> rawurlencode encodes forward slashes (and many other things). Not what
> you're looking for.
>

Note that I said "your use," and tedd is running basename on the PHP_SELF
variable before using it so the escaping of forward slashes is not an issue
here hence why I didn't mention it.

Apart from that, there is no single solution to the issue: if you're
> doing url rewrites, then you could use your route-to-url function
> instead of relying on any server variables. If your script is called
> directly instead, then use the part of the request uri up till and
> including the match for __FILE__.
>

There is a single solution... know what URL you should be using at any given
point without making it depend on user(/browser)-supplied data. If you don't
know what URL you should be using at any given point, your architecture is
fundamentally flawed, whether than means passing it into shared code from
elsewhere, or using a single block of code to generate your URLs. In my
opinion you should never be generating URLs based on the URL that was used
to request the page.

If you must generate it using that source, rawurlencode is still the way to
go. To get around the forward slash issue, replace all / with ~~~ (or
similar text that won't be modified by rawurlencode), run rawurlencode then
replace ~~~ with /. Wrap that up in a nice little function, and apply
liberally.

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

[PHP] Object Query Language optimization

[jean-baptiste verrey]

hi folks,

I'm writing an Object Query Language which is pretty simple, you do request
such as
*SELECT e.*,c.firstName *
*FROM employee e *
*JOIN contact c ON e*
*WHERE e.id=*?

(queries don't get much more complicated than that, you have multiple
alias.fieldName in the select, then multiple joins)

I'm trying to find the best way to get all the informations.
At the moment I am doing a preg_match that simply verify that the whole
syntax is good , but to separate all the information i have to separate the
query in sub parts (select, from , join, where) and do a preg_match_all on
them.

So my questions are :
- is there a better way to do this?

- about regular expression : (that would directly solve my problem)
if you do
preg_match('!(([a-z])+)!','abcabc',$matches);
echo '';print_r($matches);echo '';
you get only the last letter, is there a way to get all of them ??? (using a
regular expression and only preg_match, no preg_match_all)
http://www.regular-expressions.info/captureall.html

Regards,

JB

Re: [PHP] Script ID?

[Peter Lind]

On 21 May 2011 16:18, Stuart Dallas  wrote:
> On Sat, May 21, 2011 at 3:11 PM, tedd  wrote:
>
>> Hi gang:
>>
>> Okay, so,what's the "best" (i.e., most secure) way for your script to
>> identify itself *IF* you plan on using that information later, such as the
>> value in an action attribute in a form?
>>
>> For example, I was using:
>>
>> $self = basename($_SERVER['SCRIPT_NAME']);
>>
>> 
>>
>> However, that was susceptible to XSS.
>>
>> http://www.mc2design.com/blog/php_self-safe-alternatives
>>
>> says a simple action="#" would work.
>>
>> But is there a better way?
>>
>> What would do you do solve this?
>>
>
> If you want the form to submit to the same URL that generated the form, I'd
> recommend using $_SERVER['REQUEST_URI']. You can also omit the action
> attribute entirely which, in my experience, will cause the browser to submit
> to the current URL. I have no idea whether that's part of the HTML spec, but
> that's the behaviour I've always observed.

REQUEST_URI is as susceptible to XSS as the others. Omitting url
entirely (in case of posting a form, say) works in most browsers but
is known to fail in others (atm I can't recall which but Google should
know). Both '?' and '#' will generally work, but are prone to problems
with the base element.

> Alternatively, by my reckoning, you could make your use of PHP_SELF safe by
> applying rawurlencode to $self when you put it in the action, but that's
> only after 30 seconds of thinking about it.

rawurlencode encodes forward slashes (and many other things). Not what
you're looking for.

Apart from that, there is no single solution to the issue: if you're
doing url rewrites, then you could use your route-to-url function
instead of relying on any server variables. If your script is called
directly instead, then use the part of the request uri up till and
including the match for __FILE__.

Regards
Peter

-- 

WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP] Script ID?

[admin]

So sorry Tedd,

I was typing away with the rest of that and after hitting send I
notice all I sent was the define.

define('PAGE_1', 1);
I use define because sometimes I want o know what script included another
and if that script does not have a defined value I do not allow it to run.
Just be careful I noticed with integers it will fail to hold the value if it
has a leading zero.






Richard L. Buskirk


-Original Message-
From: tedd [mailto:t...@sperling.com] 
Sent: Saturday, May 21, 2011 10:11 AM
To: PHP General
Subject: [PHP] Script ID?

Hi gang:

Okay, so,what's the "best" (i.e., most secure) way for your script to 
identify itself *IF* you plan on using that information later, such 
as the value in an action attribute in a form?

For example, I was using:

$self = basename($_SERVER['SCRIPT_NAME']);



However, that was susceptible to XSS.

http://www.mc2design.com/blog/php_self-safe-alternatives

says a simple action="#" would work.

But is there a better way?

What would do you do solve this?

Cheers,

tedd


-- 
---
http://sperling.com/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Script ID?

[Ashley Sheridan]

On Sat, 2011-05-21 at 10:11 -0400, tedd wrote:

> Hi gang:
> 
> Okay, so,what's the "best" (i.e., most secure) way for your script to 
> identify itself *IF* you plan on using that information later, such 
> as the value in an action attribute in a form?
> 
> For example, I was using:
> 
> $self = basename($_SERVER['SCRIPT_NAME']);
> 
> 
> 
> However, that was susceptible to XSS.
> 
> http://www.mc2design.com/blog/php_self-safe-alternatives
> 
> says a simple action="#" would work.
> 
> But is there a better way?
> 
> What would do you do solve this?
> 
> Cheers,
> 
> tedd
> 
> 
> -- 
> ---
> http://sperling.com/
> 


I never use the action attribute if the form is posting to itself, as
the default action I've seen in any browser since the days of IE3 has
been for forms to post to themselves if no other action has been
specified. Having read that link you posted, I realise that missing the
action attribute out altogether would too be affected by the 
element.

However, looking at the output of $_SERVER again, couldn't you just
subtract the value of PATH_INFO from the value of PHP_SELF, or only use
the portion of PHP self that didn't include PATH_INFO?



I've just tested this here and it seems to do the trick

-- 
Thanks,
Ash
http://www.ashleysheridan.co.uk

RE: [PHP] Script ID?

[admin]

I use 
define('page1, 1);


Richard L. Buskirk



-Original Message-
From: tedd [mailto:t...@sperling.com] 
Sent: Saturday, May 21, 2011 10:11 AM
To: PHP General
Subject: [PHP] Script ID?

Hi gang:

Okay, so,what's the "best" (i.e., most secure) way for your script to 
identify itself *IF* you plan on using that information later, such 
as the value in an action attribute in a form?

For example, I was using:

$self = basename($_SERVER['SCRIPT_NAME']);



However, that was susceptible to XSS.

http://www.mc2design.com/blog/php_self-safe-alternatives

says a simple action="#" would work.

But is there a better way?

What would do you do solve this?

Cheers,

tedd


-- 
---
http://sperling.com/

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] Script ID?

[Stuart Dallas]

On Sat, May 21, 2011 at 3:11 PM, tedd  wrote:

> Hi gang:
>
> Okay, so,what's the "best" (i.e., most secure) way for your script to
> identify itself *IF* you plan on using that information later, such as the
> value in an action attribute in a form?
>
> For example, I was using:
>
> $self = basename($_SERVER['SCRIPT_NAME']);
>
> 
>
> However, that was susceptible to XSS.
>
> http://www.mc2design.com/blog/php_self-safe-alternatives
>
> says a simple action="#" would work.
>
> But is there a better way?
>
> What would do you do solve this?
>

If you want the form to submit to the same URL that generated the form, I'd
recommend using $_SERVER['REQUEST_URI']. You can also omit the action
attribute entirely which, in my experience, will cause the browser to submit
to the current URL. I have no idea whether that's part of the HTML spec, but
that's the behaviour I've always observed.

Alternatively, by my reckoning, you could make your use of PHP_SELF safe by
applying rawurlencode to $self when you put it in the action, but that's
only after 30 seconds of thinking about it.

-Stuart

-- 
Stuart Dallas
3ft9 Ltd
http://3ft9.com/

[PHP] Script ID?

[tedd]

Hi gang:

Okay, so,what's the "best" (i.e., most secure) way for your script to 
identify itself *IF* you plan on using that information later, such 
as the value in an action attribute in a form?


For example, I was using:

$self = basename($_SERVER['SCRIPT_NAME']);



However, that was susceptible to XSS.

http://www.mc2design.com/blog/php_self-safe-alternatives

says a simple action="#" would work.

But is there a better way?

What would do you do solve this?

Cheers,

tedd


--
---
http://sperling.com/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] A Review Request

[tedd]

At 2:49 PM -0400 5/19/11, Joshua Kehn wrote:

On May 19, 2011, at 2:44 PM, Andre Polykanine wrote:


 Hello Alex,

 Two (stupid?) questions:
 1. Why PHP_SELF is better than SCRIPT_NAME?
 2. Why strcmp() is better than just comparing?

 --
 With best regards from Ukraine,
 Andre
 Skype: Francophile
 My blog: http://oire.org/menelion (mostly in Russian)
 Twitter: http://twitter.com/m_elensule
 Facebook: http://facebook.com/menelion


No idea about the first, and I've never used strcmp() before for an 
equality check. If there is something I'm missing I would love to 
know.


Regards,

-Josh


-Josh:

The function strcmp() simply evaluates two strings and reports back 
-1, 0, or 1 depending upon their  alphabetical relationship.



Cheers,

tedd


--
---
http://sperling.com/

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP] Re: Date validation

[Geoff Lane]

I'm posting here for completeness as I've now rolled my own date
validator (code follows my sig). It allows almost all valid 'English'
formats except ordinal day values (1st, 3rd, etc.) Because I'm in UK
and writing for a UK audience, I've parsed ambiguous dates as d/m/y.
Those writing for places where m/d/y is the convention will probably
want to alter the tests in the second if ... elseif construct. It's a
bit long-winded, but by all means use or modify if it's any use to
you.

Best regards,

Geoff

---8<--

function is_date ($str){
$dateOK = TRUE;
if (stristr($str, "/")){
$aryDate = explode ("/", $str);
} elseif (stristr($str, "-")){
$aryDate = explode ("-", $str);
} elseif (stristr($str, " ")){
$aryDate = explode (" ", $str);
} else {
$dateOK = FALSE;
}
if (count($aryDate) != 3){
// we don't have the correct number of date parts
$dateOK = FALSE;
}
if ($dateOK) {
// trim any leading or trailing whitespace
for ($i = 0; $i < count($aryDate); $i++){
$aryDate[$i] = trim($aryDate[$i]);
}
// determine which value is month and which is day
if (!is_numeric($aryDate[0])){
$month = $aryDate[0];
$day = $aryDate[1];
} elseif (!is_numeric($aryDate[1])){
$day = $aryDate[0];
$month = $aryDate[1];
} elseif ($aryDate[1] <= 12){
$day = $aryDate[0];
$month = $aryDate[1];
} else {
$month = $aryDate[0];
$day = $aryDate[1];
}
$year = $aryDate[2];
// Expand 2-digit years to 4 digits. Cut-off is current year + 10.
if (strlen($year) != 4){
$now = date('y') + 10;
$year = $year - $now < 0 ? '20' . $year : '19' . $year;
// check for correct year length
if (strlen($year) != 4){
// we didn't start with two digits
$dateOK = FALSE;
}
}
// Convert month names to month numbers
if (!is_numeric($month)){
$aryMonth = array('nowt', 'jan', 'feb', 'mar', 'apr', 'may', 'jun', 
'jul', 'aug', 'sep', 'oct', 'nov', 'dec');
$month = strtolower(substr($month, 0, 3));
foreach ($aryMonth AS $key => $value){
if ($value == $month){
$month = $key;
}
}
}
$dateOK = $dateOK && checkdate($month, $day, $year);
}
return ($dateOK);
}


-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHPCaptcha / Securimage 2.0.2 - Authentication Bypass - SOS-11-007

[Andre Polykanine]

Hello Lists,

Sorry for my rude words but...
there  are  already  too  many  websites  that  either don't give us a
possibility  to  get  an  audio  file  instead of those damned captcha
images;  there are lots of others (such as Msn) where the audio is too
distorted  to  be  heard.  It's  not my f***ing problem that you can't
protect  your  audio  against  spammers.  I'm  blind,  you know, and I
*can't*  see  the  image,  because I have no sight at all! And I'm not
alone, there are thousands of us only in the USA.
So  make  conclusions:  if  you make a popular site, one day you might
have deep problems and maybe even lawsuits from people.
Sorry again, it's been just a really painful thing for us for years.



-- 
With best regards from Ukraine,
Andre
Skype: Francophile
My blog: http://oire.org/menelion (mostly in Russian)
Twitter: http://twitter.com/m_elensule
Facebook: http://facebook.com/menelion

 Original message 
From: Lists 
To: php-general@lists.php.net
Date created: , 1:03:06 AM
Subject: [PHP] PHPCaptcha / Securimage 2.0.2 - Authentication Bypass - 
SOS-11-007


  
Sense of Security - Security Advisory - SOS-11-007

Release Date.   20-May-2011
Last Update.-
Vendor Notification Date.   04-Apr-2011
Product.Securimage / PHPCaptcha 
Platform.   PHP
Affected versions.  1.0.4 - 2.0.2
Severity Rating.Medium
Impact. Authentication bypass
Attack Vector. Remote without authentication
Solution Status.Vendor workaround 
(remove securimage_play.php)
CVE reference. Not yet assigned

Details.
PHPCaptcha, also known as Securimage, is a popular Open Source PHP
CAPTCHA library. It is also used in popular WordPress plugins such as
the 'Fast Secure Contact Form'. Insufficient distortion in the audio
version of the CAPTCHA allows an attacker to quickly decode the CAPTCHA
by performing basic binary analysis of the generated audio file. The
issue is compounded by the fact that even if the audio feature of the
CAPTCHA has been disabled, it can still be accessed by forceful
browsing to the /secure_play.php URI.

Proof of Concept.
Proof of concept code that works against the example_form.php page and
the MP3 file format provided with the standard PHPCaptcha package 
available from www.phpcaptcha.org is available at:

http://www.senseofsecurity.com.au/advisories/SOS-11-007.zip 

Proof of concept code is only available for the MP3 version of the
audio, however the WAV audio format is also affected by the same
vulnerability.

Solution.
Remove the script securimage_play.php and disable the use of the Audio
CAPTCHA.

Discovered by.
Phil Taylor from Sense of Security Labs.

About us.
Sense of Security is a leading provider of information security and 
risk management solutions. Our team has expert skills in assessment
and assurance, strategy and architecture, and deployment through to
ongoing management. We are Australia's premier application penetration
testing firm and trusted IT security advisor to many of the country's
largest organisations.

Sense of Security Pty Ltd 
Level 8, 66 King St
Sydney NSW 2000
AUSTRALIA

T: +61 (0)2 9290 
F: +61 (0)2 9290 4455
W: http://www.senseofsecurity.com.au
E: i...@senseofsecurity.com.au
Twitter: @ITsecurityAU

The latest version of this advisory can be found at:
http://www.senseofsecurity.com.au/advisories/SOS-11-007.pdf 

Other Sense of Security advisories can be found at:
http://www.senseofsecurity.com.au/research/it-security-advisories.php

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP] PHPCaptcha / Securimage 2.0.2 - Authentication Bypass - SOS-11-007

[Ashley Sheridan]

"Lists"  wrote:

>Sense of Security - Security Advisory - SOS-11-007
>
>Release Date.   20-May-2011
>Last Update.-
>Vendor Notification Date.   04-Apr-2011
>Product.Securimage / PHPCaptcha
>Platform.   PHP
>Affected versions.  1.0.4 - 2.0.2
>Severity Rating.Medium
>Impact. Authentication bypass
>Attack Vector. Remote without authentication
>Solution Status.Vendor workaround
>(remove securimage_play.php)
>CVE reference. Not yet assigned
>
>Details.
>PHPCaptcha, also known as Securimage, is a popular Open Source PHP
>CAPTCHA library. It is also used in popular WordPress plugins such as
>the 'Fast Secure Contact Form'. Insufficient distortion in the audio
>version of the CAPTCHA allows an attacker to quickly decode the CAPTCHA
>by performing basic binary analysis of the generated audio file. The
>issue is compounded by the fact that even if the audio feature of the
>CAPTCHA has been disabled, it can still be accessed by forceful
>browsing to the /secure_play.php URI.
>
>Proof of Concept.
>Proof of concept code that works against the example_form.php page and
>the MP3 file format provided with the standard PHPCaptcha package
>available from www.phpcaptcha.org is available at:
>
>http://www.senseofsecurity.com.au/advisories/SOS-11-007.zip
>
>Proof of concept code is only available for the MP3 version of the
>audio, however the WAV audio format is also affected by the same
>vulnerability.
>
>Solution.
>Remove the script securimage_play.php and disable the use of the Audio
>CAPTCHA.
>
>Discovered by.
>Phil Taylor from Sense of Security Labs.
>
>About us.
>Sense of Security is a leading provider of information security and
>risk management solutions. Our team has expert skills in assessment
>and assurance, strategy and architecture, and deployment through to
>ongoing management. We are Australia's premier application penetration
>testing firm and trusted IT security advisor to many of the country's
>largest organisations.
>
>Sense of Security Pty Ltd
>Level 8, 66 King St
>Sydney NSW 2000
>AUSTRALIA
>
>T: +61 (0)2 9290 
>F: +61 (0)2 9290 4455
>W: http://www.senseofsecurity.com.au
>E: i...@senseofsecurity.com.au
>Twitter: @ITsecurityAU
>
>The latest version of this advisory can be found at:
>http://www.senseofsecurity.com.au/advisories/SOS-11-007.pdf
>
>Other Sense of Security advisories can be found at:
>http://www.senseofsecurity.com.au/research/it-security-advisories.php
>
>--
>PHP General Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php

If you have to remove the audio part, you might as well remove the whole thing. 
It would prevent any blind or hard of seeing user from accessing said sites.




Thanks
Ash
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php