In-house CMS now GPL, looking for testers (bugs and security) and/or developers

[darkfreaks]

this should be alot safer from CSS injection.

 

function BBCode($text)
{
$BBCode = array('[b]' => '<b>', '[/b]' => '</b>',
'[i]' => '<i>', '[/i]' => '</i>',
'[u]' => '<u>', '[/u]' => '</u>',
'
[left]' => '<div style="text-align:left">', '[/left]
' => '</div>',
'
[center]' => '<div style="text-align:center">', '[/center]
' => '</div>',
'
[right]' => '<div style="text-align:right">', '[/right]
' => '</div>');
$parsedtext = str_ireplace(array_keys($BBCode), array_values($BBCode), $text);
return $parsedtext;
}
$parsedtext = str_ireplace(array_keys($BBCode), array_values($BBCode), $text);
return $parsedtext;
}
$text = BBCode("[b][i][u]HELLO[/u][/i][/b]");
echo $text; 

 

you can modify it with your code as well.

[darkfreaks]

sorry tired *XSS injection

[Tarential]

I am using htmlentities because I understand it to actually convert more characters than htmlspecialchars. I take my understanding from this post on Stack Overflow:

http://stackoverflow.com/questions/46483/htmlentities-vs-htmlspecialchars

 

They advise that htmlspecialchars is enough in most situations, but that htmlentities converts a superset of characters. It seems to match the PHP documentation. Is there a reason you suggest that htmlentities is not secure?

 

I use strip_tags for aesthetic reasons, not security ones. This way people won't end up with tags in their messages by accident (if they don't realize, for example, that full html is not allowed then it is stripped automatically). After being stripped, htmlentities then handles the sanitization.

 

Following up, I've convinced myself to be un-lazy and uploaded the latest code to the demo page. The brute force protection should be in place and working now (but it is untested), and an interesting new feature some people might like to try (just to see it in action) is the improved file manager. Bulk file manipulation is a breeze now!

 

Thanks for the updates.

 

Edit: By the way, did the script you use for testing ever successfully inject javascript code anywhere, or was it just flagged as vulnerable? If so, can I see the code that exploited it?

[ComGuar]

This script for testing have bugs.

 

Files listed in robots.txt but not linked

Vulnerability description

This file is listed in robots.txt but it's not linked anywhere in the site.

Affected items

/info

The impact of this vulnerability

Possible sensitive information disclosure.

How to fix this vulnerability

In robots.txt you should only include files or directories linked on the site.

 

other than that you seem to be good. but i have been fooled before.

 

even I disabled complete site in robots.txt and there is no /info directory.

[darkfreaks]

@ OP:

URL encoded GET input /index_php was set to " onmouseover=prompt(949327) bad="

The input is reflected inside a tag element between double quotes.

 

fix this you fix your cross site scripting issue.

 

 

@ComGuar: /info/ might not actually exist but according to your robots.txt file it is being disallowed. i checked manually instead of scanning. if it is not being  actually used it will be indexed by crawlers even if it is disallowed. might want to take it off.

[Tarential]

I assume this is the output from the scanner you used? I don't use any GET vars called index_php or similar variations, so I'm not sure what it is indicating.

 

Can you give me an example of a request which results in Javascript code being inserted?

[Christian F.]

Yes, htmlentities () encodes a lot more characters than htmlspecialchars (). However, the latter only encodes the characters that needs to be encoded. There is no point in adding a lot of unnecessary encoding, so htmlspecialchars () is all you need.

Same goes for strip_tags (), actually. Since you're using htmlspecialchars () there is no need to strip the tags, as they're made harmless by the encoding. In fact, strip_tags () can cause you to throw away legit input, since it doesn't validate HTML. That's why it's not recommended to use.

[darkfreaks]

@ OP your best bet would be using the multidimensional array function for BBcode i provided it DOES NOT use strip_tags or htmlentities

[Tarential]

Ok, perhaps I didn't say it right the first time. I know what htmlentities does, I know what strip_tags does, and I know what my algorithm is doing. I am aware that using strip_tags is an unnecessary addition to the filtration process, assuming one wishes to allow HTML tags, which I do not. I am also aware that htmlentities encodes all special characters whether they be dangerous or not.

 

However, none of these things is a vulnerability. I've been told by darkfreaks that there is a vulnerability in some sort of unfiltered GET data, but he will not give me an example of a request which results in actually inserting Javascript code. This example is all I require so that I may fix the problem. Thank you.

[darkfreaks]

@OP: i would assume you have unfiltered $_GET data  being passed into the function.

//unfiltered get input
$input = $_GET['input'];

sanitized input:

//strip tags from input occasionally encode special chars
$input = filter_input(INPUT_GET,'input',FILTER_SANITIZE_STRING);

[Tarential]

Thank you, but that doesn't help me. I know how these vulnerabilities happen. You posted that your scanner picked something up. I'd like to know what your scanner found. If it is a false positive, or if you don't know how to get more details from the software, just say so please. I've done manual checks already and I didn't find anything wrong. As a matter of standard practice I filter all my input, so either this is something I missed or it is a false positive. More information would help me a lot in determining which of the two it is. Thanks.

[darkfreaks]

technically i don't have to do anything when the .txt file no lionger exists and neither does the demo site.

[Tarential]

You never had to do anything. I made and make no demands, I simply made the request that since you did scan, and you seemed to be attempting to help, you provide me with the information that your scanner provided you. If this request seems unreasonable to you, it is fully your right to ignore it.

 

That said, the site is still up, but I think I know why you can't see it. I had a bug that was causing an endless loop in my 404 pages one night (hence why I don't normally push my code to the demo server til after it is tested, but I was in a hurry for other reasons), and before I realized what was causing the problems with my Linode I had quickly scanned the logs and used iptables to block an IP which seemed to be making weird requests. In retrospect, I see that was probably your scanner. I've unblocked the IP address now and I apologize for the confusion.

 

I want to say this again: I am not trying to make demands of you, I am simply trying to be clear about which information would help me most. I'm grateful that you are spending your free time to help me. I don't feel that you are obliged towards me in any way and even if you choose to stop now I appreciate all the help you gave me already.

 

If, on the other hand, you should feel so inclined as to continue helping, I believe you will be able to access the site again now. I would very much appreciate more details as to precisely what type of request results in exploitable code being inserted. Thanks.

[darkfreaks]

SSL weak ciphers

Vulnerability description

The remote host supports the use of SSL ciphers that offer either weak encryption or no encryption at all.

This vulnerability affects Server.

Discovered by: Scripting (ssl_ping.script).

The impact of this vulnerability

 

Attack details

Weak SSL ciphers (SSL3 on port 443):

SSL3_CK_RSA_RC4_40_MD5 - Low strength

SSL3_CK_RSA_RC2_40_MD5 - Low strength

SSL3_CK_RSA_DES_40_CBC_SHA - Low strength

SSL3_CK_RSA_DES_64_CBC_SHA - Low strength

SSL3_CK_EDH_RSA_DES_40_CBC_SHA - Low strength

SSL3_CK_EDH_RSA_DES_64_CBC_SHA - Low strength

 

 

also the XSS is a false positive i have looked it up. but you might want to update your SSL Ciphers.  will look for an updated version of this scanner

[Pikachu2000]

@ darkfreaks

 

Rules Regarding "Exploit Scanners"

 

Use of exploit scanners can be an effective way to discover exploits on a website, so we have no intention of banning posting scanner results. But these scanners can also return bogus results.

 

Secondly: Give a man a fish and you feed him for a day. Teach a man to fish and you feed him for a lifetime.

 

As of now, posting scanner results is only allowed under the following conditions:

 

1) You must share the name and how to get the scanner

2) You absolutely MUST explain every item in the result (why is this a risk, not just because the scanner says so)

 

As with all forum rules, ignoring these could lead to moderation action. Ignorance of these rules is not a defense.

[darkfreaks]

@ pikachu

 

1. Acunetix

 

 

Also i am aware scanners give bogus results i was not aware that it was a false positive until i manually checked.

 

 

 

also i am aware that no action will be taken against me as long as i post  the reason that the code is at risk and why it is.

 

 

 

[darkfreaks]

@Pickachu: oops my bad i see why you posted that  :

 

 

anyhow updated to latest version of Acunetix.

 

 

it is telling me you are running Apache 2.2.16 which as of 2011 has several security flaws in it.  if you are not using this version no worries.

 

however if in the event you are might want to upgrade to a newer version => 2.2.19

 

Dowload Apache

 

 

[Tarential]

Hi again! Thanks for the updates. I've just spent half an hour in the #debian IRC channel discussing Apache versions and security. They inform me that security problems are often patched backwards in versions and that even though I'm running 2.2.16 it is very likely that the actual vulnerabilities are not present. However, just in case, they asked me if your scanner provides a CVE number which I can then check to see if it has been patched.

 

I also updated my virtualhost configurations to not permit low security cipher suites. I believe I've been able to test this myself (I get rejected when I use openssl s_client with low or medium strength ciphers or sslv2), but if you happen to check again to confirm that would also be nice

 

I'm always happy to be more secure. You've been a big help.

[darkfreaks]

Ciphers have been fixed

 

 

CVE-2011-3192 hope this helps.

[Tarential]

http://security-tracker.debian.org/tracker/CVE-2011-3192

 

Confirmed fixed in squeeze 2.2.16 ^^ Thanks very much.

[darkfreaks]

so was it unpatched or should i mark it as a false positive

[Tarential]

I believe it is a false positive based on version number. Since Debian backports security fixes, even though Apache is version 2.2.16 it has the latest security updates.

[darkfreaks]

http://www.dotdeb.org/2012/05/09/security-php-5-4-3-and-php-5-3-13/

 

something it also picked up on and by reading that i do believe it is possible at least upgrading the PHP version. to fix in debian 6 squeeze.

[Tarential]

Thanks for the heads up. I've checked on the CVEs and the good folks at Debian have backported those fixes as well. I have always been a Debian fan, and this helps to show why

[darkfreaks]

marked this as solved if they have both been patched already.