SQL injection is possible. User parameters submitted will be formulated into a SQL query for database processing. If the query is built by simple 'string concatenation', it is possible to modify the meaning of the query by carefully crafting the parameters. Depending on the access right and type of database used, tampered query can be used to retrieve sensitive information from the database or execute arbitrary code. MS SQL and PostGreSQL, which supports multiple statements, may be exploited if the database access right is more powerful.
This can occur in URL query strings, POST paramters or even cookies. Currently check on cookie is not supported by Paros. You should check SQL injection manually as well as some blind SQL injection areas cannot be discovered by this check.
URL
Parameter
action=“后面屏蔽 霍霍”
Solution
Do not trust client side input even if there is client side validation. In general,
If the input string is numeric, type check it.
If the application used JDBC, use PreparedStatement or CallableStatement with parameters passed by '?'
If the application used ASP, use ADO Command Objects with strong type checking and parameterized query.
If stored procedure or bind variables can be used, use it for parameter passing into query. Do not just concatenate string into query in the stored procedure!
Do not create dynamic SQL query by simple string concatentation.
Use minimum database user privilege for the application. This does not eliminate SQL injection but minimize its damage. Eg if the application require reading one table only, grant such access to the application. Avoid using 'sa' or 'db-owner'.
Reference
The OWASP guide at http://www.owasp.org/documentation/guide
For Oracle database, refer to http://www.integrigy.com/info/IntegrigyIntrotoSQLInjectionAttacks.pdf
Medium (Warning)
Cross site scripting
Description
Cross-site scripting or HTML injection is possible. Malicious script may be injected into the browser which appeared to be genuine content from the original site. These scripts can be used to execute arbitrary code or steal customer sensitive information such as user password or cookies.
Very often this is in the form of a hyperlink with the injected script embeded in the query strings. However, XSS is possible via FORM POST data, cookies, user data sent from another user or shared data retrieved from database.
Currently this check does not verify XSS from cookie or database. They should be checked manually if the application retrieve database records from another user's input.
URL
Parameter
UserInfoForSearch.“屏蔽屏蔽屏蔽”
URL
Parameter
UserInfoForSearch..“屏蔽屏蔽屏蔽”
URL
Parameter
UserInfoForSearch..“屏蔽屏蔽屏蔽”
URL
Parameter
UserInfoForSearch..“屏蔽屏蔽屏蔽”
URL
Parameter
UserInfoForSearch..“屏蔽屏蔽屏蔽”
URL
Parameter
UserInfoForSearch..“屏蔽屏蔽屏蔽”
URL
Parameter
UserInfoForSearch..“屏蔽屏蔽屏蔽”
URL
Parameter
UserInfoForSearch..“屏蔽屏蔽屏蔽”
URL
Parameter
UserInfoForSearch..“屏蔽屏蔽屏蔽”
URL
Parameter
UserInfoForSearch..“屏蔽屏蔽屏蔽”
URL
Parameter
UserInfoForSearch..“屏蔽屏蔽屏蔽”
Solution
Do not trust client side input even if there is client side validation. Sanitize potentially danger characters in the server side. Very often filtering the <, >, " characters prevented injected script to be executed in most cases. However, sometimes other danger meta-characters such as ' , (, ), /, &, ; etc are also needed.
In addition (or if these characters are needed), HTML encode meta-characters in the response. For example, encode < as <
Reference
The OWASP guide at http://www.owasp.org/documentation/guide
Private IP such as x.x.x.x, x.x.x.x, 192.168.x.x is found in the HTTP response body. This can be used in exploits on internal system.
URL
Other information
URL
Other information
URL
Other information
Solution
Remove the private IP address from the HTTP response body. For comments, use jsp/asp comment instead of HTML/javascript comment which can be seen by client browsers.
扫一扫
1156
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
