#ORACLE PL/SQL Secure Coding Practices #INFOSEC – Please tell me how your database system is designed @bgoug will get this presentation first

The more you tell me, the more ways I can find I can find to attack your system. All I need is one little sql injection bug and trust me, it is most likely there, you just don’t know it yet.

execute process_row(’EMPLOYEES where 1=2 union select owner, name, text from all_source order by owner, name, line –’);

Problem #1 for you, Opportunity #1 for bad guys. Guess what, all of your source code just leaked out from your database.

Problem #2 for you, Opportunity #2 for bad guys. Not putting your your code into packages. If you put your pl/sql into a procedure or a function, I can extract your code from all_source, learn about your system and tailor my attack.

What do you need to do? Put your code into packages. If the code is in a package, the only thing I can get is the package specification.

Problem #2 for you, Opportunity #2 for bad guys. Comments in your package specification. Hey, I’ve been <humor> smacking junior developers with a boat paddle </humor> for years about not commenting their code. The good part is they eventually get it and put in comments. The bad part is comments are being put into the package specification. Some comments are quite verbose and <humor> I really like that</humor>. You are telling the bad guys everything they need to know to exploit your system.

What you need to do? Move all of your comments to the top of the package body and use inline comments in the package body. Again, when I extract your source code, if it’s in a package then I can only get the package specification.

Here is a sample of one of my packages specifications. You are not going to derive too much information from this except maybe what calls it.


AUTHID current_user 



-- constant declarations

sVersion CONSTANT VARCHAR2(10) := '20161026.1';




When I put on my penetration testing hat, all of your source code and comments make my job much easier. I learn exactly how your system is designed and coded and that lets me find all kinds of ways to exploit your system. <humor>Please don’t make my pen testing work too easy, customers will start thinking they are paying me too much money.</humor> And please for goodness sake, make the bad guys life harder; because if you do, they will likely move on to an easier target.

November is going to be a busy month. #ECOUG and #BGOUG

I stopped tracking the the miles I fly years ago. It seems every other month I’m in another timezone at a conference, learning from the best in the industry. Well in November I will be fortunate to stay in my timezone; speaking at the East Coast Oracle Users Group in Raleigh, North Carolina. https://www.eastcoastoracle.org/index.htm Once I return from ECOUG, I’m on a flight to Sofia Bulgaria for the Bulgarian Oracle Users Group Autumn conference http://www.bgoug.org/en/events/details/98.html, seven hour time difference from Baltimore, Maryland.

What do we get out of my spending so much time traveling?

  1. I get privilege of teaching people how to secure their data. We are seeing the same security mistakes everywhere we go. Therefore I’ve dedicated some of my time to show you these mistakes and how to correct them.
    1. Setting up the Oracle Database environment. A lot of these mistakes are the result of an attitude of, we have strong parameter security, so the proper effort is not put into securing the database. Other mistakes are the result of not understanding how the database works. Sample question: If you take existing data and put it into an encrypted tablespace, is your data encrypted? The answer is yes and no. Yes your data is now encrypted but you still have unencrypted ghost data. I’ll walk you through how to address this ghost data. Most of these mistakes can be easily corrected, others require more engineering.
    2. Application Architecture. We have been designing applications the same way for over thirty years and then wonder why data is spilling. We need to fundamentally rethink how we design database applications. I will show you a secure application architecture that will dramatically improve the security of your data.
    3. Coding Standards. The biggest issue I see in database applications is SQL Injection bugs. I remember sitting in a meeting when the Director of Application Development told me. “There are no SQL Injection bugs in our applications.” We started the pen test and it did not take us very long to extract all of their source code from the database and from there we started extracting their data. Don’t be too confidant, there will always someone out there smarter then you (and smarter than me.)
  2. We get the privilege of learning from the best in the industry. The list of speakers at ECOUG AND BGOUG reads like a Who’s Who from the Oracle space. There are ACE Directors, ACE’s, ACE Associates and Oracle Product Mangers from all over the world along with some that are rising to ACE status. If you want to learn from the best of the best, come on out. Here is the best part, these guys are not only the smartest they are also the nicest people you will encounter. We are always happy to sit down over a beer or two and discuss your specific situation or just chew the fat.

Do you want to kick your career up a several notches? Ask us how to get involved with speaking at Oracle Users Groups.

The BGOUG Conference Agenda: http://www.bgoug.org/upload/events_files/1019_Agenda_201611_Pravets_EN_3.pdf

The ECOUG Conference Agenda: https://www.eastcoastoracle.org/PDF_files/2016/ECO_16_SAG_v2.pdf