How to Hack an Apex Application - Anton Nielsen, C2 Consulting (formerly Oracle)
Apex developers are very responsive to these security risks by enhancing Apex frequently.
It's actually easier to close the holes in the Apex framework than it is in other areas.
There's some high school kid out there who will try to hack your web application.
Legend of Apex
Mike Hichwa was tasked w/ building a new calendaring system, so instead he built a framework for building calendering, which became Oracle Scheduler -> Flowbuilder -> Oracle Platform -> Oracle Project Marvel -> HTML DB -> Apex
First determine how important your data is to you, how secure applications need to be?
Can set up 2 different window w/in Firefox by setting up aliases based on IP address (in Windows/system32/drivers/netc??)
Authorization scheme: BEGIN RETURN :APP_USER = 'ADMIN'; END;
- If your user changes his URL to get to pages not authorized and you didn't secure all your pages with that author scheme, they can sneak in.
Tip: you can report at the application level for Security that will list which of your authorization schemes is use on which pages.
Tip: You can call the Apex API to reset the authorization on your application.
- Choosing the timing of when you perform the authorization scheme check. Do you check every page rendering or do you do it once at login.
Quicker at login, but you can also reset the authorizations at various points in your application. That might be very useful if user needs new role and you don't want to force them to log out when you've updated their rights.
- Application-Level Items - You do not want the user to set the values from the browser. For example, if you create an app-level item to hold the username, don't just let them type in a value!
Use Session State protection on Application Items
- More than Securing a Button! Hackers adding functionality to themselves via saving your web page source and hacking it. For example, notice there's a doSubmit(Save) and create a DELETE when they don't have Delete rights.
***Tip*** if you save the source, you can get the server components by including BASE HREF
***Cool Tool*** - ZoomIt tool for zooming your screen
- Conditionally display-only items - Say you conditionally set the Salary field to Read Only. You can use WebDeveloper to find hidden item that shows Salary field on page, so if you change that value in WebDeveloper and Submit, which would update the database.
Solution: You need to check the authorization of the user in a Validation when your Update process runs. Maybe even log who the user was that tried to update something they shouldn't.
- Conditionally displaying based on Role - RTFM
Cross-Site Scripting (XSS)
Vulnerability is if you allow user to type in value and you display value w/o stripping out HTML.
Solution: Use Strip HTML setting on the region
Vulnerability when you use substitution names, where Apex doesn't automatically strip HTML (it escapes them instead - ). But if you use a PL/SQL Region and code
BEGIN HTP.P(:P2_NAME); END;
Never use concatenation in your PL/SQL regions! Vulnerable to SQL injection.
Beware SQL Injection
If you write code where they can enter values that are concatenated into your SQL query or use ''&P1_SEARCH_VALUE.''
Hack can also be done with Bind variables but is harder
Especially if you have a report that uses Function that Returns SQL.
User can type in SELECT that closes original query and UNIONS with user_tables.
Don't "Just Trust" Downloaded code
E.g. example code from Denes has warning, but in German!
Check any AJAX or JS code before running
Real WHERE Clauses*
- Secure value at the back end, using VIEWs and VPDs.
- You could also do a Validation on the page that restrict values they can update to. This will get around their ability to hack around LOVs.
- Database package that reads apex item instead of using value passed by URL, but that means you can't create Apex report using Wizard.
- Session State Protection feature does some testing, but mostly URL tampering, but using a checksum to make sure URL item values weren't changes.
However, in 3.0, you can use WebDeveloper to alter page value for column you're linking to, and then delete the Checksum value on the page, so Apex won't do checksum testing.
V3.1 fixes this by changing Hidden Items to Hidden and Protected, so it can't be hacked. The Apex Wizards use these by defaults (except in Tabular Forms).
- Make field that you're going to pass (emp_id) into Display as Text (do not save state). You can also use Conditional Display and never show that item. But if your user opens multiple browser tabs w/ multiple records, this fix will cause a checksum error.
V3.1 adds runtime where clause to secure this type of thing. If you use this, turn off SSP.
Don't run these unless you're at Apex 3.1.1.
Additional security issues to guard against XSS, Session Rejoin and cookie stealing.
Production Environments with Builder Access
Issues prior to V3.1.
User Profile/Password Change Screens, Custom Authentication, publically accessible exports
Need to be extra-careful.
***TIP*** For production only - Restrict user's access to tables to only those you grant them to.
In Development environment