Jeremy, CVE is littered with these kinds of issues, for PHP especially. The scripts are often open source, fully-functional packages that just happen to have lots of security issues. Sometimes the root cause is buried fairly deep in the code, but the people who find these bugs often care only about the attack. The CVE descriptions are often straightforward.
To find the best options, I'd grab CVEs that mention scripts ending in a .php extension, select the ones with both milw0rm and Secunia references, then examine the milw0rm reference to see if the researcher lists a download URL for the product (this is probably 25% or more of all milw0rms, so you won't have to look very hard). While you'll get a lot of XSS, SQL injection, and file inclusion, you'll also get more subtle issues like eval injection, file upload, redirect-without-exit, static code injection, variable extraction, and other issues that affect most interpreted languages (although the vuln research emphasis is on PHP). Since CVE descriptions are well-formed for well-known vuln types, you could find the weird ones pretty quickly. - Steve _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com) as a free, non-commercial service to the software security community. _______________________________________________
