I Need someone to repair security holes in Payment Processor php script (SolarPAy).
SolarPay (the version we are trying to adapt to be fit for it's stated purpose) is a 7MB file, of which only 500KB is NOT dedicated to the affilliate program to sell SolarPay.
SolarPay lacks polish and sophistication.
The SolarPay HTML is badly structured and very hard to understand.
The PHP scripts are severely spaghetti code. (Needs to be reviewed)
SolarPay is hard-coded to use MySQL and requires the HTTPD to connect to the database as the user that owns the database (an SQL injection attack could result in the dropping of all tables, or worse).
SolarPay is hard-coded to use non-transactional table types. A user who closes the browser window mid-request could leave half-completed transactions (money withdrawn, but not sent to the transferee, or worse)
SolarPay is not based on a journaled accounting system.
SolarPay requires substantial amounts of PHP scripts to be writeable by the HTTPD process.
There is no seperation between business logic, authentication and authorization, and presentation
Passwords are not encrypted.
Database access passwords, etc are stored under the server's documentroot.
Session handling code appears to re-invent the wheel.
Session handling code requires database writes and reads on every page view.
There are session hijacking Vulnerabilities.
Database access code is spread throughout the scripts, not all in one place.
Many notification emails do not have adequate information for a merchant to complete a transaction.
Merchants who use a pay now button with a notification URL are sent the solarpay username and password of their customers.
Oh yeah, and the special accounts all have the same hard-coded password, too.