Description

SQL injection may be possible.

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
• http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=23
• http://www.spidynamics.com/whitepapers/WhitepaperSQLInjection.pdf
• For Oracle database, refer to http://www.integrigy.com/info/IntegrigyIntrotoSQLInjectionAttacks.pdf

Description

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.

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
• http://www.sqlsecurity.com/DesktopDefault.aspx?tabid=23
• http://www.spidynamics.com/whitepapers/WhitepaperSQLInjection.pdf
• For Oracle database, refer to http://www.integrigy.com/info/IntegrigyIntrotoSQLInjectionAttacks.pdf

Description

AUTOCOMPLETE attribute is not disabled in HTML FORM/INPUT element containing password type input. Passwords may be stored in browsers and retrieved.

Solution

Turn off AUTOCOMPLETE attribute in form or individual input elements containing password by using AUTOCOMPLETE='OFF'

Reference

http://msdn.microsoft.com/library/default.asp?url=/workshop/author/forms/autocomplete_ovr.asp

Description

Lotus Domino default files found.

Solution

Remove default files.

Reference

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.

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 &lt;

Reference

• The OWASP guide at http://www.owasp.org/documentation/guide
• http://www.technicalinfo.net/papers/CSS.html
• http://www.cgisecurity.org/articles/xss-faq.shtml
• http://www.cert.org/tech_tips/malicious_code_FAQ.html
• http://sandsprite.com/Sleuth/papers/RealWorld_XSS_1.html

Description

Certain parameter caused error page or Java stacktrace to be displayed. This indicated lack of exception handling and potential areas for further exploit.

Solution

Identify the cause of the error and fix it. Do not trust client side input and enforece tight check in the server side. Besides, catch the exception properly. Use a generic 500 error page for internal server error.

Reference

Description

Miscellenous include files, backup, unused or obsolete files exist as indicated. If these files contain program source, information such as server logic or ODBC/JDBC user ID and passwords may be revealed since these file extension may not be processed by the web server.

Solution

Remove backup, unused or obsolete files. For include files, carefully choose the suffix to prevent information disclosure.

Reference

Description

Miscellenous include files, backup, unused or obsolete files exist as indicated. If these files contain program source, information such as server logic or ODBC/JDBC user ID and passwords may be revealed since these file extension may not be processed by the web server.

Solution

Remove backup, unused or obsolete files. For include files, carefully choose the suffix to prevent information disclosure.

Reference