| Subject: | Fixes urgently needed. |
|---|
| Summary: | Package rating comment |
|---|
| Messages: | 3 |
|---|
| Author: | Artur Graniszewski |
|---|
| Date: | 2011-01-10 10:20:44 |
|---|
| Update: | 2011-01-10 12:21:50 |
|---|
| |
|
|
Artur Graniszewski rated this package as follows:
| Utility: | Insufficient |
|---|
| Consistency: | Good |
|---|
| Documentation: | Good |
|---|
| Examples: | Good |
|---|
|
|
 Artur Graniszewski - 2011-01-10 10:20:53 Fixes urgently needed.
There are many potential SQL injection vectors of attack. For example in RegisterEvent()
 Alexander Selifonov - 2011-01-10 11:53:31 - In reply to message 1 from Artur GraniszewskiWe talk about SQL injection when there is some user entered data to be saved in DB.
In our case all SQL operators are composed by PHP script, so document type and ID should be prepared and passed by PHP programmer, not the final user. It's his (programmer) responsibility to intercept suspicious "document names" and convert / strip them.
For example, if user works with numeric ID of document, You could use intval() to convert user passed number.
Artur Graniszewski - 2011-01-10 12:21:50 - In reply to message 2 from Alexander SelifonovEven your own example file can be exploited by the SQL injection. IMHO If you use some kind of data abstraction layer like DB class, you should provide some input sanitization.
Whats more there is some inconsistency concerning input sanitization. For example in some methods you are trying to sanitize input parameters (see __construct() ), and in some - no. This can lead to mistakes done by other developers who will be expecting that you use input sanitization in every of your method.
|
