Skip to Main Content

APEX

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Sql Injection and Cross Site scripting (Reflected)

VivRichardsOct 7 2021

Hello
This was the issue faced by our IT security team and they sent a long message for Sql injection and cross site scripting on a particular database (user acceptance testing) on a specific day. This is not even to a specific page and it was just calling the main application itself . Unsure if this issue which are outside of Apex page if there is any security issue can still be handled by Application developer and if someone can throw light on this .
Thanks

Issues are as below
SQL injection vulnerabilities arise when user-controllable data is incorporated into database SQL queries in an unsafe manner. An attacker can supply crafted input to break out of the data context in which their input appears and interfere with the structure of the surrounding query.
A wide range of damaging attacks can often be delivered via SQL injection, including reading or modifying critical application data, interfering with application logic, escalating privileges within the database and taking control of the database server.
Evidence as given by security team:

  1. <our url>/pls/apex_<db>/wwv_flow.js_messages
    The p_app_id parameter appears to be vulnerable to SQL injection attacks. The payload ' was submitted in the p_app_id parameter, and a database error message was returned. You should review the contents of the error message, and the application’s handling of other input, to confirm whether a vulnerability is present.
    The database appears to be Oracle.
    The application should handle errors gracefully and prevent SQL error messages from being returned in responses.
    The error returned was as below

Failed to parse target procedure
wwv_flow.js_messages: SIGNATURE (parameter names) MISMATCH
VARIABLES IN FORM NOT IN PROCEDURE:
NON-DEFAULT VARIABLES IN PROCEDURE NOT IN FORM: P_APP_ID,P_LANG,P_VERSION

DAD name: apex_<db>
PROCEDURE : wwv_flow.js_messages
URL : <our url>/wwv_flow.js_messages
PARAMETERS :

ENVIRONMENT:

PLSQL_GATEWAY=WebDb
GATEWAY_IVERSION=2
SERVER_SOFTWARE=Oracle-Application-Server-11g
GATEWAY_INTERFACE=<Gateway>
SERVER_PORT= <port number?
SERVER_NAME=<our server>
REQUEST_METHOD=GET
QUERY_STRING=
PATH_INFO=/wwv_flow.js_messages
SCRIPT_NAME=/pls/apex_<db>
REMOTE_HOST=
REMOTE_ADDR=<our addr>
SERVER_PROTOCOL=HTTP/1.1
REQUEST_PROTOCOL=HTTP
REMOTE_USER=APEX_PUBLIC_USER
ORACLE_SSO_USER=
OSSO_IDLE_TIMEOUT_EXCEEDED=
OSSO_USER_GUID=
HTTP_CONTENT_LENGTH=

In the above case can the above error message be controlled by meaningful application error messages

The next issue is for Cross site scripting (reflected)
Reflected cross-site scripting vulnerabilities arise when data is copied from a request and echoed into the application’s immediate response in an unsafe way. An attacker can use the vulnerability to construct a request that, if issued by another application user, will cause JavaScript code supplied by the attacker to execute within the user’s browser in the context of that user’s session with the application.
Evidence:
<our url>/apex_db/f
The name of an arbitrarily supplied URL parameter is copied into the HTML document as plain text between tags. The payload was submitted in the name of an arbitrarily supplied URL parameter. This input was echoed unmodified in the application’s response.
This behavior demonstrates that it is possible to inject new HTML tags into the returned document. An attempt was made to identify a full proof-of-concept attack for injecting arbitrary JavaScript but this was not successful. You should manually examine the application’s behavior and attempt to identify any unusual input validation or other obstacles that may be in place.
The application appears to be blocking the usual proof-of-concept test string used by Burp, so an alternate test string was used.
The response does not state that the content type is HTML. The issue is only directly exploitable if a browser can be made to interpret the response as HTML. The following browsers may interpret the response as HTML:
Internet Explorer 11 (Compatibility Mode)
More details on these vulnerabilities can be found on customer portal.
The attachment is as below
image.png

Comments
Post Details
Added on Oct 7 2021
0 comments
1,540 views