 | News Feed |
 | Jobs Feed |
Sections
|
| feed this: |  |
Rafael Dohms' Blog: PHP Security Are you paying attention?
by Chris Cornutt October 02, 2009 @ 12:27:18
In a recent post to his blog Rafael Dohms reminds readers to not forget about the security of their applications because it can be "a huge mistake which can take a turn for the worse."
I have ran into lots of excuses for ignoring security in the past, one of them is the recurring "This is just a simple application, it has no sensitive data", this may be a valid point for the person repeating it like a mantra, especially because this person is generally suffering of great pressures , short timeframes and a lack of proper management ready to deal with web development. [...] Whatever the reason is for neglecting security the consequences can escalate much higher then the "non-sensitive data" of the application.
He looks at a specific case where a security issue was found in a large Brazillian mobile company's website that was caused by improper filtering on a $_GET parameter, leaving it open to possible attack. Through it, he could load the information for sensitive system-related files and found more on the machine than just the site he was working with.
voice your opinion now!
security opinion vulnerability
Gareth Heyes' Blog: PHP self return of the slash
by Chris Cornutt September 25, 2009 @ 10:31:24
In this new post to his blog Gareth Heyes points out a legacy issue that those running older PHP4-based code might want to look into:
I thought about something I found ages ago in PHP4 and it's been long enough now. This is also quite funny because my server is vulnerable to this. So what happens if you escape PHP_SELF with htmlentities($_SERVER['PHP_SELF'], ENT_QUOTES)? Safe from XSS? I hope so. Safe from everything? Well not really or at least it didn't used to be.
He gives a simple example of how the PHP_SELF issue can be used to change the form's target just by using a few well-placed slashes. Thankfully, this seems to be only back in the world of PHP4, so those working with PHP5 should be safe.
voice your opinion now!
phpself xss vulnerability slash
CyberInsecure.com: Half-Million Sites Mostly Running PHPBB Forum Software Hacked In Latest Attack
by Chris Cornutt May 13, 2008 @ 14:04:38
According to the CyberInsecure.com website around a half-million websites running PHPBB were hacked in a large coordinated effort.
More than half a million websites have been compromised in a new round of attacks that hacked domains in order to infect unsuspecting users' PCs with a variety of trojans. This ongoing campaign includes new malware hosting domains and new trojans variations. All of the sites are running older or misconfigured versions of "phpBB," an open-source message forum manager. Open-source popular applications like phpBB tend to be often targeted by mass scanning and exploiting tools.
The hack redirected visitors through several steps ultimately ending up on a page that tried to take advantage of errors in older Internet Explorer and RealPlayer versions. The article talks about exactly which viruses could have caused the problems and the wide range of sites (both in topic and location) that were effected.
The best way to protect you and your PHPBB install from something like this happening is to get the latest version of the software and learn how to configure it correctly.
voice your opinion now!
phpbb forum software attack hack redirect vulnerability
Secunia.com: Joomla! Multiple Vulnerabilities
by Chris Cornutt July 30, 2007 @ 10:26:00
Secunia.com reports that multiple vulnerabilities have been found in the Joomla! content management system:
Some vulnerabilities have been reported in Joomla!, which can be exploited by malicious people to conduct session fixation attacks, cross-site scripting attacks or HTTP response splitting attacks.
The issues are marked as "less critical" but users should still update to the latest version to avoid these issues:
- Certain unspecified input passed in com_search, com_content and mod_login is not properly sanitised before being returned to a user
- Input passed to the "url" parameter is not properly sanitised before being returned to the user. This can be exploited to insert arbitrary HTTP headers.
- An error exists in the handling of sessions and can be exploited to hijack another user's session by tricking the user into logging in after following a specially crafted link.
See the original advisory post here.
voice your opinion now!
joomla content management cms vulnerability secunia joomla content management cms vulnerability secunia
|
Community Events
Don't see your event here? Let us know!
|