Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #14648 > unrolled thread

php challenge

Back to article view | Back to comp.lang.php

Contents

  php challenge Kiuhnm Mnhuik <gandalf23@mail.com> - 2014-11-27 09:12 -0800
    Re: php challenge Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-27 13:40 -0500
      Re: php challenge Kiuhnm Mnhuik <gandalf23@mail.com> - 2014-11-27 11:31 -0800
        Re: php challenge Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-27 15:27 -0500
          Re: php challenge Kiuhnm Mnhuik <gandalf23@mail.com> - 2014-11-27 15:55 -0800
            Re: php challenge Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-27 20:35 -0500
              Re: php challenge Kiuhnm Mnhuik <gandalf23@mail.com> - 2014-11-27 19:16 -0800
                Re: php challenge Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-28 09:10 -0500
                  Re: php challenge Kiuhnm Mnhuik <gandalf23@mail.com> - 2014-11-28 12:52 -0800
                    Re: php challenge Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-28 16:32 -0500
    Re: php challenge "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-27 19:52 +0100
      Re: php challenge Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-27 14:18 -0500
        Re: php challenge "Christoph M. Becker" <cmbecker69@arcor.de> - 2014-11-27 21:12 +0100
          Re: php challenge Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-27 15:28 -0500
      Re: php challenge Kiuhnm Mnhuik <gandalf23@mail.com> - 2014-11-27 12:00 -0800
        Re: php challenge Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-27 15:30 -0500
          Re: php challenge Kiuhnm Mnhuik <gandalf23@mail.com> - 2014-11-27 15:02 -0800
            Re: php challenge Jerry Stuckle <jstucklex@attglobal.net> - 2014-11-27 20:36 -0500
              Re: php challenge Kiuhnm Mnhuik <gandalf23@mail.com> - 2014-11-27 19:18 -0800

#14648 — php challenge

Here's the picture of the challenge "other2" found on http://halls-of-valhalla.org/:
  http://i.share.pho.to/fd1e7ff4_o.png
AFAIK, we can only control $_GET['username'] and $_GET['password']. Since there aren't any evals or similar I don't see how we can inject code.
I suspect we have to set $loggedIn to true, but how?

Note: I think this post is in-topic because every programmer should know as much as possible about security.

[toc] | [next] | [standalone]

#14649

On 11/27/2014 12:12 PM, Kiuhnm Mnhuik wrote:
> Here's the picture of the challenge "other2" found on http://halls-of-valhalla.org/:
>   http://i.share.pho.to/fd1e7ff4_o.png
> AFAIK, we can only control $_GET['username'] and $_GET['password']. Since there aren't any evals or similar I don't see how we can inject code.
> I suspect we have to set $loggedIn to true, but how?
> 
> Note: I think this post is in-topic because every programmer should know as much as possible about security.
> 

Just because you don't do any evals doesn't mean your code is secure.
SQL injection, for instance, is a much more common vulnerability.

Not knowing what checkLogin() does (and not willing to waste a lot of
time trying to find the code somewhere on the site), it's impossible to
determine what would be valid username/password.

I might suggest you follow the "Get Help on this Challenge" link.  They
know more about their code than anyone here.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14652

On Thursday, November 27, 2014 7:40:21 PM UTC+1, Jerry Stuckle wrote:
> On 11/27/2014 12:12 PM, Kiuhnm Mnhuik wrote:
> > Here's the picture of the challenge "other2" found on http://halls-of-valhalla.org/:
> >   http://i.share.pho.to/fd1e7ff4_o.png
> > AFAIK, we can only control $_GET['username'] and $_GET['password']. Since there aren't any evals or similar I don't see how we can inject code.
> > I suspect we have to set $loggedIn to true, but how?
> > 
> > Note: I think this post is in-topic because every programmer should know as much as possible about security.
> > 
> 
> Just because you don't do any evals doesn't mean your code is secure.
> SQL injection, for instance, is a much more common vulnerability.

SQLi doesn't seem to work here.

> I might suggest you follow the "Get Help on this Challenge" link.  They
> know more about their code than anyone here.

Unfortunately, the forum is kinda inactive.

[toc] | [prev] | [next] | [standalone]

#14656

On 11/27/2014 2:31 PM, Kiuhnm Mnhuik wrote:
> On Thursday, November 27, 2014 7:40:21 PM UTC+1, Jerry Stuckle wrote:
>> On 11/27/2014 12:12 PM, Kiuhnm Mnhuik wrote:
>>> Here's the picture of the challenge "other2" found on http://halls-of-valhalla.org/:
>>>   http://i.share.pho.to/fd1e7ff4_o.png
>>> AFAIK, we can only control $_GET['username'] and $_GET['password']. Since there aren't any evals or similar I don't see how we can inject code.
>>> I suspect we have to set $loggedIn to true, but how?
>>>
>>> Note: I think this post is in-topic because every programmer should know as much as possible about security.
>>>
>>
>> Just because you don't do any evals doesn't mean your code is secure.
>> SQL injection, for instance, is a much more common vulnerability.
> 
> SQLi doesn't seem to work here.
> 

Not knowing what's in the functions being called, there is no way to tell.

>> I might suggest you follow the "Get Help on this Challenge" link.  They
>> know more about their code than anyone here.
> 
> Unfortunately, the forum is kinda inactive.
> 

Which still does not mean it's not the best place to ask.  Did you try?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14663

On Thursday, November 27, 2014 9:27:57 PM UTC+1, Jerry Stuckle wrote:
> On 11/27/2014 2:31 PM, Kiuhnm Mnhuik wrote:
> > On Thursday, November 27, 2014 7:40:21 PM UTC+1, Jerry Stuckle wrote:
> >> On 11/27/2014 12:12 PM, Kiuhnm Mnhuik wrote:
> >>> Here's the picture of the challenge "other2" found on http://halls-of-valhalla.org/:
> >>>   http://i.share.pho.to/fd1e7ff4_o.png
> >>> AFAIK, we can only control $_GET['username'] and $_GET['password']. Since there aren't any evals or similar I don't see how we can inject code.
> >>> I suspect we have to set $loggedIn to true, but how?
> >>>
> >>> Note: I think this post is in-topic because every programmer should know as much as possible about security.
> >>>
> >>
> >> Just because you don't do any evals doesn't mean your code is secure.
> >> SQL injection, for instance, is a much more common vulnerability.
> > 
> > SQLi doesn't seem to work here.
> > 
> 
> Not knowing what's in the functions being called, there is no way to tell.

If the login succeeds or you can force a time delay, then it works. 99.9% of SQLi attacks are blind. I just said that, in this case, it doesn't *seem* to work. You almost never have the source code.

> >> I might suggest you follow the "Get Help on this Challenge" link.  They
> >> know more about their code than anyone here.
> > 
> > Unfortunately, the forum is kinda inactive.
> > 
> 
> Which still does not mean it's not the best place to ask.  Did you try?

Yes, I did.

[toc] | [prev] | [next] | [standalone]

#14664

On 11/27/2014 6:55 PM, Kiuhnm Mnhuik wrote:
> On Thursday, November 27, 2014 9:27:57 PM UTC+1, Jerry Stuckle wrote:
>> On 11/27/2014 2:31 PM, Kiuhnm Mnhuik wrote:
>>> On Thursday, November 27, 2014 7:40:21 PM UTC+1, Jerry Stuckle wrote:
>>>> On 11/27/2014 12:12 PM, Kiuhnm Mnhuik wrote:
>>>>> Here's the picture of the challenge "other2" found on http://halls-of-valhalla.org/:
>>>>>   http://i.share.pho.to/fd1e7ff4_o.png
>>>>> AFAIK, we can only control $_GET['username'] and $_GET['password']. Since there aren't any evals or similar I don't see how we can inject code.
>>>>> I suspect we have to set $loggedIn to true, but how?
>>>>>
>>>>> Note: I think this post is in-topic because every programmer should know as much as possible about security.
>>>>>
>>>>
>>>> Just because you don't do any evals doesn't mean your code is secure.
>>>> SQL injection, for instance, is a much more common vulnerability.
>>>
>>> SQLi doesn't seem to work here.
>>>
>>
>> Not knowing what's in the functions being called, there is no way to tell.
> 
> If the login succeeds or you can force a time delay, then it works. 99.9% of SQLi attacks are blind. I just said that, in this case, it doesn't *seem* to work. You almost never have the source code.
>

Untrue.  Most SQL injection attacks are well planned out and executed.
And hackers have the source code more often than you think - look at all
the open source software in use today.

Even if they don't, there are some regular attempts that hackers try for
those sites which are not secure.

>>>> I might suggest you follow the "Get Help on this Challenge" link.  They
>>>> know more about their code than anyone here.
>>>
>>> Unfortunately, the forum is kinda inactive.
>>>
>>
>> Which still does not mean it's not the best place to ask.  Did you try?
> 
> Yes, I did.
> 

Interesting, since I didn't see a question from you on their forum.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14666

On Friday, November 28, 2014 2:35:39 AM UTC+1, Jerry Stuckle wrote:
> On 11/27/2014 6:55 PM, Kiuhnm Mnhuik wrote:
> > On Thursday, November 27, 2014 9:27:57 PM UTC+1, Jerry Stuckle wrote:
> >> On 11/27/2014 2:31 PM, Kiuhnm Mnhuik wrote:
> >>> On Thursday, November 27, 2014 7:40:21 PM UTC+1, Jerry Stuckle wrote:
> >>>> On 11/27/2014 12:12 PM, Kiuhnm Mnhuik wrote:
> >>>>> Here's the picture of the challenge "other2" found on http://halls-of-valhalla.org/:
> >>>>>   http://i.share.pho.to/fd1e7ff4_o.png
> >>>>> AFAIK, we can only control $_GET['username'] and $_GET['password']. Since there aren't any evals or similar I don't see how we can inject code.
> >>>>> I suspect we have to set $loggedIn to true, but how?
> >>>>>
> >>>>> Note: I think this post is in-topic because every programmer should know as much as possible about security.
> >>>>>
> >>>>
> >>>> Just because you don't do any evals doesn't mean your code is secure.
> >>>> SQL injection, for instance, is a much more common vulnerability.
> >>>
> >>> SQLi doesn't seem to work here.
> >>>
> >>
> >> Not knowing what's in the functions being called, there is no way to tell.
> > 
> > If the login succeeds or you can force a time delay, then it works. 99.9% of SQLi attacks are blind. I just said that, in this case, it doesn't *seem* to work. You almost never have the source code.
> >
> 
> Untrue.  Most SQL injection attacks are well planned out and executed.
> And hackers have the source code more often than you think - look at all
> the open source software in use today.
> 
> Even if they don't, there are some regular attempts that hackers try for
> those sites which are not secure.

I don't have any numbers, but almost any books and tutorials on this topic teach a black-box approach.
For instance, the book "SQL Injection Attacks and Defense" says:
  As the presence of SQL injection is commonly tested for remotely (i.e., over the Internet as part of an application penetration test) you usually don't have the opportunity to look at the source code to review the structure of the query into which you are injecting. This often leads to a need to perform much of your testing through inference - that is, "If I see this, then this is probably happening at the back end."

> >>>> I might suggest you follow the "Get Help on this Challenge" link.  They
> >>>> know more about their code than anyone here.
> >>>
> >>> Unfortunately, the forum is kinda inactive.
> >>>
> >>
> >> Which still does not mean it's not the best place to ask.  Did you try?
> > 
> > Yes, I did.
> > 
> 
> Interesting, since I didn't see a question from you on their forum.

I sent posts about other challenges (I found some errors) and I'm still waiting.

[toc] | [prev] | [next] | [standalone]

#14668

On 11/27/2014 10:16 PM, Kiuhnm Mnhuik wrote:
> On Friday, November 28, 2014 2:35:39 AM UTC+1, Jerry Stuckle wrote:
>> On 11/27/2014 6:55 PM, Kiuhnm Mnhuik wrote:
>>> On Thursday, November 27, 2014 9:27:57 PM UTC+1, Jerry Stuckle wrote:
>>>> On 11/27/2014 2:31 PM, Kiuhnm Mnhuik wrote:
>>>>> On Thursday, November 27, 2014 7:40:21 PM UTC+1, Jerry Stuckle wrote:
>>>>>> On 11/27/2014 12:12 PM, Kiuhnm Mnhuik wrote:
>>>>>>> Here's the picture of the challenge "other2" found on http://halls-of-valhalla.org/:
>>>>>>>   http://i.share.pho.to/fd1e7ff4_o.png
>>>>>>> AFAIK, we can only control $_GET['username'] and $_GET['password']. Since there aren't any evals or similar I don't see how we can inject code.
>>>>>>> I suspect we have to set $loggedIn to true, but how?
>>>>>>>
>>>>>>> Note: I think this post is in-topic because every programmer should know as much as possible about security.
>>>>>>>
>>>>>>
>>>>>> Just because you don't do any evals doesn't mean your code is secure.
>>>>>> SQL injection, for instance, is a much more common vulnerability.
>>>>>
>>>>> SQLi doesn't seem to work here.
>>>>>
>>>>
>>>> Not knowing what's in the functions being called, there is no way to tell.
>>>
>>> If the login succeeds or you can force a time delay, then it works. 99.9% of SQLi attacks are blind. I just said that, in this case, it doesn't *seem* to work. You almost never have the source code.
>>>
>>
>> Untrue.  Most SQL injection attacks are well planned out and executed.
>> And hackers have the source code more often than you think - look at all
>> the open source software in use today.
>>
>> Even if they don't, there are some regular attempts that hackers try for
>> those sites which are not secure.
> 
> I don't have any numbers, but almost any books and tutorials on this topic teach a black-box approach.
> For instance, the book "SQL Injection Attacks and Defense" says:
>   As the presence of SQL injection is commonly tested for remotely (i.e., over the Internet as part of an application penetration test) you usually don't have the opportunity to look at the source code to review the structure of the query into which you are injecting. This often leads to a need to perform much of your testing through inference - that is, "If I see this, then this is probably happening at the back end."
>

Remember - this book is only the opinion of one author.  You should
learn by studying hackers and what they do, not by reading a book by
someone who may or may not know what he's talking about.

>>>>>> I might suggest you follow the "Get Help on this Challenge" link.  They
>>>>>> know more about their code than anyone here.
>>>>>
>>>>> Unfortunately, the forum is kinda inactive.
>>>>>
>>>>
>>>> Which still does not mean it's not the best place to ask.  Did you try?
>>>
>>> Yes, I did.
>>>
>>
>> Interesting, since I didn't see a question from you on their forum.
> 
> I sent posts about other challenges (I found some errors) and I'm still waiting.
> 

Another reason to find another site.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14669

On Friday, November 28, 2014 3:10:41 PM UTC+1, Jerry Stuckle wrote:
> On 11/27/2014 10:16 PM, Kiuhnm Mnhuik wrote:
> > On Friday, November 28, 2014 2:35:39 AM UTC+1, Jerry Stuckle wrote:
> >> On 11/27/2014 6:55 PM, Kiuhnm Mnhuik wrote:
> >>> On Thursday, November 27, 2014 9:27:57 PM UTC+1, Jerry Stuckle wrote:
> >>>> On 11/27/2014 2:31 PM, Kiuhnm Mnhuik wrote:
> >>>>> On Thursday, November 27, 2014 7:40:21 PM UTC+1, Jerry Stuckle wrote:
> >>>>>> On 11/27/2014 12:12 PM, Kiuhnm Mnhuik wrote:
> >>>>>>> Here's the picture of the challenge "other2" found on http://halls-of-valhalla.org/:
> >>>>>>>   http://i.share.pho.to/fd1e7ff4_o.png
> >>>>>>> AFAIK, we can only control $_GET['username'] and $_GET['password']. Since there aren't any evals or similar I don't see how we can inject code.
> >>>>>>> I suspect we have to set $loggedIn to true, but how?
> >>>>>>>
> >>>>>>> Note: I think this post is in-topic because every programmer should know as much as possible about security.
> >>>>>>>
> >>>>>>
> >>>>>> Just because you don't do any evals doesn't mean your code is secure.
> >>>>>> SQL injection, for instance, is a much more common vulnerability.
> >>>>>
> >>>>> SQLi doesn't seem to work here.
> >>>>>
> >>>>
> >>>> Not knowing what's in the functions being called, there is no way to tell.
> >>>
> >>> If the login succeeds or you can force a time delay, then it works. 99.9% of SQLi attacks are blind. I just said that, in this case, it doesn't *seem* to work. You almost never have the source code.
> >>>
> >>
> >> Untrue.  Most SQL injection attacks are well planned out and executed.
> >> And hackers have the source code more often than you think - look at all
> >> the open source software in use today.
> >>
> >> Even if they don't, there are some regular attempts that hackers try for
> >> those sites which are not secure.
> > 
> > I don't have any numbers, but almost any books and tutorials on this topic teach a black-box approach.
> > For instance, the book "SQL Injection Attacks and Defense" says:
> >   As the presence of SQL injection is commonly tested for remotely (i.e., over the Internet as part of an application penetration test) you usually don't have the opportunity to look at the source code to review the structure of the query into which you are injecting. This often leads to a need to perform much of your testing through inference - that is, "If I see this, then this is probably happening at the back end."
> >
> 
> Remember - this book is only the opinion of one author.  You should
> learn by studying hackers and what they do, not by reading a book by
> someone who may or may not know what he's talking about.

That book is a classic written by experts in the field.
They definitely know what they're talking about.
If you don't have any solid evidence that what you say is the truth, then I'll go with the experts...
 
> >>>>>> I might suggest you follow the "Get Help on this Challenge" link.  They
> >>>>>> know more about their code than anyone here.
> >>>>>
> >>>>> Unfortunately, the forum is kinda inactive.
> >>>>>
> >>>>
> >>>> Which still does not mean it's not the best place to ask.  Did you try?
> >>>
> >>> Yes, I did.
> >>>
> >>
> >> Interesting, since I didn't see a question from you on their forum.
> > 
> > I sent posts about other challenges (I found some errors) and I'm still waiting.
> > 
> 
> Another reason to find another site.

Almost every site has something to offer. Some of the challenges on that site were very good and instructive.

[toc] | [prev] | [next] | [standalone]

#14670

On 11/28/2014 3:52 PM, Kiuhnm Mnhuik wrote:
> On Friday, November 28, 2014 3:10:41 PM UTC+1, Jerry Stuckle wrote:
>> On 11/27/2014 10:16 PM, Kiuhnm Mnhuik wrote:
>>> On Friday, November 28, 2014 2:35:39 AM UTC+1, Jerry Stuckle wrote:
>>>> On 11/27/2014 6:55 PM, Kiuhnm Mnhuik wrote:
>>>>> On Thursday, November 27, 2014 9:27:57 PM UTC+1, Jerry Stuckle wrote:
>>>>>> On 11/27/2014 2:31 PM, Kiuhnm Mnhuik wrote:
>>>>>>> On Thursday, November 27, 2014 7:40:21 PM UTC+1, Jerry Stuckle wrote:
>>>>>>>> On 11/27/2014 12:12 PM, Kiuhnm Mnhuik wrote:
>>>>>>>>> Here's the picture of the challenge "other2" found on http://halls-of-valhalla.org/:
>>>>>>>>>   http://i.share.pho.to/fd1e7ff4_o.png
>>>>>>>>> AFAIK, we can only control $_GET['username'] and $_GET['password']. Since there aren't any evals or similar I don't see how we can inject code.
>>>>>>>>> I suspect we have to set $loggedIn to true, but how?
>>>>>>>>>
>>>>>>>>> Note: I think this post is in-topic because every programmer should know as much as possible about security.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Just because you don't do any evals doesn't mean your code is secure.
>>>>>>>> SQL injection, for instance, is a much more common vulnerability.
>>>>>>>
>>>>>>> SQLi doesn't seem to work here.
>>>>>>>
>>>>>>
>>>>>> Not knowing what's in the functions being called, there is no way to tell.
>>>>>
>>>>> If the login succeeds or you can force a time delay, then it works. 99.9% of SQLi attacks are blind. I just said that, in this case, it doesn't *seem* to work. You almost never have the source code.
>>>>>
>>>>
>>>> Untrue.  Most SQL injection attacks are well planned out and executed.
>>>> And hackers have the source code more often than you think - look at all
>>>> the open source software in use today.
>>>>
>>>> Even if they don't, there are some regular attempts that hackers try for
>>>> those sites which are not secure.
>>>
>>> I don't have any numbers, but almost any books and tutorials on this topic teach a black-box approach.
>>> For instance, the book "SQL Injection Attacks and Defense" says:
>>>   As the presence of SQL injection is commonly tested for remotely (i.e., over the Internet as part of an application penetration test) you usually don't have the opportunity to look at the source code to review the structure of the query into which you are injecting. This often leads to a need to perform much of your testing through inference - that is, "If I see this, then this is probably happening at the back end."
>>>
>>
>> Remember - this book is only the opinion of one author.  You should
>> learn by studying hackers and what they do, not by reading a book by
>> someone who may or may not know what he's talking about.
> 
> That book is a classic written by experts in the field.
> They definitely know what they're talking about.
> If you don't have any solid evidence that what you say is the truth, then I'll go with the experts...
>  
>>>>>>>> I might suggest you follow the "Get Help on this Challenge" link.  They
>>>>>>>> know more about their code than anyone here.
>>>>>>>
>>>>>>> Unfortunately, the forum is kinda inactive.
>>>>>>>
>>>>>>
>>>>>> Which still does not mean it's not the best place to ask.  Did you try?
>>>>>
>>>>> Yes, I did.
>>>>>
>>>>
>>>> Interesting, since I didn't see a question from you on their forum.
>>>
>>> I sent posts about other challenges (I found some errors) and I'm still waiting.
>>>
>>
>> Another reason to find another site.
> 
> Almost every site has something to offer. Some of the challenges on that site were very good and instructive.
> 

Yes, but I prefer sites with up-to-date information and who respond to
inquiries.  I'm not very impressed by sites with information that's
years out of date and who don't respond to appropriate questions.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14650

Kiuhnm Mnhuik wrote:

> Here's the picture of the challenge "other2" found on
> http://halls-of-valhalla.org/: http://i.share.pho.to/fd1e7ff4_o.png 
> AFAIK, we can only control $_GET['username'] and $_GET['password'].
> Since there aren't any evals or similar I don't see how we can inject
> code. I suspect we have to set $loggedIn to true, but how?

If register_globals[1]=On that would be easy (because $loggedIn is not
necessarily initialized, and it is tested for being == true, instead of
=== true).  Fortunately, that misfeature had been removed as of PHP 5.4.

[1] <http://php.net/manual/en/security.globals.php>

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#14651

On 11/27/2014 1:52 PM, Christoph M. Becker wrote:
> Kiuhnm Mnhuik wrote:
> 
>> Here's the picture of the challenge "other2" found on
>> http://halls-of-valhalla.org/: http://i.share.pho.to/fd1e7ff4_o.png 
>> AFAIK, we can only control $_GET['username'] and $_GET['password'].
>> Since there aren't any evals or similar I don't see how we can inject
>> code. I suspect we have to set $loggedIn to true, but how?
> 
> If register_globals[1]=On that would be easy (because $loggedIn is not
> necessarily initialized, and it is tested for being == true, instead of
> === true).  Fortunately, that misfeature had been removed as of PHP 5.4.
> 
> [1] <http://php.net/manual/en/security.globals.php>
> 

And has been recommended AGAINST use for several years now, for this
very reason.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14655

Jerry Stuckle wrote:

>> If register_globals[1]=On that would be easy (because $loggedIn is not
>> necessarily initialized, and it is tested for being == true, instead of
>> === true).  Fortunately, that misfeature had been removed as of PHP 5.4.
>>
>> [1] <http://php.net/manual/en/security.globals.php>
> 
> And has been recommended AGAINST use for several years now, for this
> very reason.

IMO the possibility to set global variables from user input should have
never been introduced in the first place; it's even slightly more insane
than automatically escaping user input (magic_quotes_*).

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#14657

On 11/27/2014 3:12 PM, Christoph M. Becker wrote:
> Jerry Stuckle wrote:
> 
>>> If register_globals[1]=On that would be easy (because $loggedIn is not
>>> necessarily initialized, and it is tested for being == true, instead of
>>> === true).  Fortunately, that misfeature had been removed as of PHP 5.4.
>>>
>>> [1] <http://php.net/manual/en/security.globals.php>
>>
>> And has been recommended AGAINST use for several years now, for this
>> very reason.
> 
> IMO the possibility to set global variables from user input should have
> never been introduced in the first place; it's even slightly more insane
> than automatically escaping user input (magic_quotes_*).
> 

You'll get no arguments from me on that point, Christoph!

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14654

On Thursday, November 27, 2014 7:52:26 PM UTC+1, Christoph M. Becker wrote:
> Kiuhnm Mnhuik wrote:
> 
> > Here's the picture of the challenge "other2" found on
> > http://halls-of-valhalla.org/: http://i.share.pho.to/fd1e7ff4_o.png 
> > AFAIK, we can only control $_GET['username'] and $_GET['password'].
> > Since there aren't any evals or similar I don't see how we can inject
> > code. I suspect we have to set $loggedIn to true, but how?
> 
> If register_globals[1]=On that would be easy (because $loggedIn is not
> necessarily initialized, and it is tested for being == true, instead of
> === true).  Fortunately, that misfeature had been removed as of PHP 5.4.

Congratulations! You beat the challenge!
I modified the post request, but it didn't work. Then I sent a get request and it worked. Maybe the post request didn't work only because this is just a simulation.

[toc] | [prev] | [next] | [standalone]

#14658

On 11/27/2014 3:00 PM, Kiuhnm Mnhuik wrote:
> On Thursday, November 27, 2014 7:52:26 PM UTC+1, Christoph M. Becker wrote:
>> Kiuhnm Mnhuik wrote:
>>
>>> Here's the picture of the challenge "other2" found on
>>> http://halls-of-valhalla.org/: http://i.share.pho.to/fd1e7ff4_o.png 
>>> AFAIK, we can only control $_GET['username'] and $_GET['password'].
>>> Since there aren't any evals or similar I don't see how we can inject
>>> code. I suspect we have to set $loggedIn to true, but how?
>>
>> If register_globals[1]=On that would be easy (because $loggedIn is not
>> necessarily initialized, and it is tested for being == true, instead of
>> === true).  Fortunately, that misfeature had been removed as of PHP 5.4.
> 
> Congratulations! You beat the challenge!
> I modified the post request, but it didn't work. Then I sent a get request and it worked. Maybe the post request didn't work only because this is just a simulation.
> 

If they (still!) have register_globals enabled, I don't know what else
they might have screwed up.  I wouldn't trust any of their challenges
any more.  It's hard telling what other bad habits they could be teaching.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14662

On Thursday, November 27, 2014 9:30:53 PM UTC+1, Jerry Stuckle wrote:
> On 11/27/2014 3:00 PM, Kiuhnm Mnhuik wrote:
> > On Thursday, November 27, 2014 7:52:26 PM UTC+1, Christoph M. Becker wrote:
> >> Kiuhnm Mnhuik wrote:
> >>
> >>> Here's the picture of the challenge "other2" found on
> >>> http://halls-of-valhalla.org/: http://i.share.pho.to/fd1e7ff4_o.png 
> >>> AFAIK, we can only control $_GET['username'] and $_GET['password'].
> >>> Since there aren't any evals or similar I don't see how we can inject
> >>> code. I suspect we have to set $loggedIn to true, but how?
> >>
> >> If register_globals[1]=On that would be easy (because $loggedIn is not
> >> necessarily initialized, and it is tested for being == true, instead of
> >> === true).  Fortunately, that misfeature had been removed as of PHP 5.4.
> > 
> > Congratulations! You beat the challenge!
> > I modified the post request, but it didn't work. Then I sent a get request and it worked. Maybe the post request didn't work only because this is just a simulation.
> > 
> 
> If they (still!) have register_globals enabled, I don't know what else
> they might have screwed up.  I wouldn't trust any of their challenges
> any more.  It's hard telling what other bad habits they could be teaching.

What bad habit did this challenge teach?

[toc] | [prev] | [next] | [standalone]

#14665

On 11/27/2014 6:02 PM, Kiuhnm Mnhuik wrote:
> On Thursday, November 27, 2014 9:30:53 PM UTC+1, Jerry Stuckle wrote:
>> On 11/27/2014 3:00 PM, Kiuhnm Mnhuik wrote:
>>> On Thursday, November 27, 2014 7:52:26 PM UTC+1, Christoph M. Becker wrote:
>>>> Kiuhnm Mnhuik wrote:
>>>>
>>>>> Here's the picture of the challenge "other2" found on
>>>>> http://halls-of-valhalla.org/: http://i.share.pho.to/fd1e7ff4_o.png 
>>>>> AFAIK, we can only control $_GET['username'] and $_GET['password'].
>>>>> Since there aren't any evals or similar I don't see how we can inject
>>>>> code. I suspect we have to set $loggedIn to true, but how?
>>>>
>>>> If register_globals[1]=On that would be easy (because $loggedIn is not
>>>> necessarily initialized, and it is tested for being == true, instead of
>>>> === true).  Fortunately, that misfeature had been removed as of PHP 5.4.
>>>
>>> Congratulations! You beat the challenge!
>>> I modified the post request, but it didn't work. Then I sent a get request and it worked. Maybe the post request didn't work only because this is just a simulation.
>>>
>>
>> If they (still!) have register_globals enabled, I don't know what else
>> they might have screwed up.  I wouldn't trust any of their challenges
>> any more.  It's hard telling what other bad habits they could be teaching.
> 
> What bad habit did this challenge teach?
> 

Don't use sites with software that's been outdated for years.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#14667

On Friday, November 28, 2014 2:36:37 AM UTC+1, Jerry Stuckle wrote:
> On 11/27/2014 6:02 PM, Kiuhnm Mnhuik wrote:
> > On Thursday, November 27, 2014 9:30:53 PM UTC+1, Jerry Stuckle wrote:
> >> On 11/27/2014 3:00 PM, Kiuhnm Mnhuik wrote:
> >>> On Thursday, November 27, 2014 7:52:26 PM UTC+1, Christoph M. Becker wrote:
> >>>> Kiuhnm Mnhuik wrote:
> >>>>
> >>>>> Here's the picture of the challenge "other2" found on
> >>>>> http://halls-of-valhalla.org/: http://i.share.pho.to/fd1e7ff4_o.png 
> >>>>> AFAIK, we can only control $_GET['username'] and $_GET['password'].
> >>>>> Since there aren't any evals or similar I don't see how we can inject
> >>>>> code. I suspect we have to set $loggedIn to true, but how?
> >>>>
> >>>> If register_globals[1]=On that would be easy (because $loggedIn is not
> >>>> necessarily initialized, and it is tested for being == true, instead of
> >>>> === true).  Fortunately, that misfeature had been removed as of PHP 5.4.
> >>>
> >>> Congratulations! You beat the challenge!
> >>> I modified the post request, but it didn't work. Then I sent a get request and it worked. Maybe the post request didn't work only because this is just a simulation.
> >>>
> >>
> >> If they (still!) have register_globals enabled, I don't know what else
> >> they might have screwed up.  I wouldn't trust any of their challenges
> >> any more.  It's hard telling what other bad habits they could be teaching.
> > 
> > What bad habit did this challenge teach?
> > 
> 
> Don't use sites with software that's been outdated for years.

That's a good habit!

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.php

csiph-web