Okay, in regards to the ridiculous amount of post topics made to the test forum...

The presence of flood control certainly limited the number of posts that were made. The actual number of requests sent to the server exceeded successful posts by an extortionate figure.

This board doesn't appear to support guest posts, but for those that do, it means posts can be made remotely without any kind of authorisation, so long as a valid session is created. This is achieved by crafting a form in a single htm file. Even if login credentials are required in order to post, such data can still be applied to the form. Basically, this means that a user does not need to have a current connection to the target host to actually post a new thread or topic reply (or even other actions, such as private messaging).

Now the problem arises where a Javascript is called to reload the htm file, thus executing the script once again, consequently looping its action. What I did effectively rendered my system as paralysed since it consumed some 500 megabytes of resources whilst opening 30+ instances of the browser. Now I don't have the capabilities to exploit this to its fullest extent because I do not own a server. I'm not so sure this problem will be much of an issue if used by the average home user. However, for someone who does have a server and also the potential to apply or link to multiple proxies, flood control can thus be bypassed to an extent.

Worse still is if the script is located at a (malicious) web site that usually has high public traffic. Any visitor viewing a page with such scripting in it will inadvertently execute this script and consequently post a message to the target forum. This will obviously avoid the problem of flood control if multiple IP addresses are sending the requests.

Either way, whether or not a message/topic is successfully posted, traffic is still hitting the server. Persistent traffic can quite easily amount to denial of service.

The REAL problem is yet to be established. What if XSS was applied to the form action URL?

watch the titles of your posts m8.

Rule number 4

I'll let this one slide though :wink:

__________________

Okay, so I renamed it to something a bit more appropriate

By the way, I didn't realise this site is aimed towards themes and what not...I don't think it's the right place to bring this up. But maybe someone might have a knowledge of implementing something that will prevent an instance of the above example.

I'd to delete about 20+ posts of this person in the test forum.
I don't think this is an exploit or val since we can easily remove those posts/topics and ban the person that done them :wink:

__________________
read me before posting

Personally, I don't think it should be possible for people to make a post to a BB board without even being connected to the site in the first place. There needs to be a restriction on the usage of the session ID. Afterall, it is already vulnerable to attack, such as cookie stealing. And the example I tested was characteristics of a DoS attack (not that it was my intention, btw).

The problem is not a few dozen posts, or a few hundred requests...but a server that has the ability to quickly switch proxy or spoof its IP. Furthermore, if a script was created to gather the current session ID, an attack can be maintained without maintenance

Not a problem, you say?

A quick snippet and fix is to check if the $_POST came from this site and not from another, this way it can't be used like you said above.
I didn't say that is not a problem,i just said that is a problem easily fixed. But since fb doesn't listen to his community people are left alone with out any help from the original author.
I and a bud of mine which tends to be a security freak are working on my project (xero) and we are trying to make it as much secure as we can, if you are interested in testing,reporting,helping us just click on my sign.

__________________
read me before posting

The truth is, I don't know much about PHP at all But hey...I'll keep it in mind. And what's a fix if people don't know, eh?

I've just noticed something else. Might or might not be an issue, I don't know.

I was just using a proxy server that has their search bar thing at the top of the page in the header section, and as a result of this, the website printed an error on screen to the effect of...

Quote:

"Warning: Cannot modify header information - headers already sent by (output started at /home/$/public_html/phpnuke/header.php:32) in /home/$/public_html/phpnuke/includes/sessions.php on line 222"

Is it just my way of thinking, or does this suggest a problem?

Personally, I'm wondering whether the previous issue could also have specific coding in the header section. Hopefully header/sessions.php is not vulnerable to attack, but we know Includes has been used as an avenue already.

Such issue does exist, and was fixed by the community but wasn't applied in the default packed of nuke.

__________________
read me before posting

Good stuff At least it's been accounted for. And besides, I think the website in question is using v2.0.5 of phpBB 8O No wonder it has something at the bottom of the page to the effect of "you are owned by Indonesian hackers".

Okay, not so incognito any more. That handle was somewhat annoying for me, never mind anybody else :roll:

I think I've found another. Not really specific to PHP, since most BB sites are rather limited as to user input. Meaning very little HTML is accepted when posting, let alone other coding, such as Java. But, I'll try to explain the example situation to those who may be interested

Let's say we're at a profile edit facility that accepts HTML and also Java. The profile information is being inputted into a textarea. Any information, including coding, is formatted and shown on the profile viewing page in accordance.

Now, if this is put into the text box...

Code:

<textarea> text </textarea> OTHER TEXT

...closing the textarea has just closed the one the text is inputted into. So if you now go back to the profile edit, the OTHER TEXT will be displayed on the page OUTSIDE of where it should be. This means that when the page is submitted, the server will process this data as if it is the main body of the page. Obviously, anything inside the text box is treated in a specific manner, as per the CGI script that deals with it (or Perl, whatever).

Basically, the data has broken away from the main form and into the page body. Therefore, this has opened up all sorts of avenues for attack.

Am I right in saying that, or once again staring into space?