Virtual Private Database (VPD)

What is VPD?

Virtual Private Database (VPD) is a database security feature that is built into an Oracle database server, as opposed to being part of an application that is accessing the data. The user is only allowed to see the data they have been given permission to see.
VPD is a feature of Oracle Database 11g Enterprise Edition, was introduced in Oracle8i.

Why VPD?

VPD is used when the standard object privileges and associated database roles are insufficient to meet application security requirements. VPD policies can be simple or complex depending on organization’s security requirements. VPD uses application contexts to provide row-level security and fine-grained access control based on a company's security policies. Application contexts are simply key value pairs that are created in a defined namespace.
A simple VPD example might restrict access to data during business hours and a more complex VPD example might read an application context during a login trigger and enforce row level security against the ORDERS table.

No matter how users connect to the protected table (via an application, a Web interface or SQL*Plus), the result is the same. There is no "application security problem" anymore, since the access policy is attached to the table, and cannot be bypassed.

Example:

A customer can only see his orders in the 'orders' table (below), when he is listed in the 'customers' table (above).





Benefits of using VPD

Attaching Oracle Virtual Private Database security policies to database tables, views, or synonyms, rather than implementing access controls in all organization's applications, provides the following benefits:

Security: Associating a policy with a database table, view, or synonym can solve a potentially serious application security problem. Suppose a user is authorized to use an application, and then drawing on the privileges associated with that application, wrongfully modifies the database by using an ad hoc query tool, such as SQL*Plus. By attaching security policies directly to tables, views, or synonyms, fine-grained access control ensures that the same security is in force, no matter how a user accesses the data.

Simplicity: You add the security policy to a table, view, or synonym only once, rather than repeatedly adding it to each of your table-based, view-based, or synonym-based applications.

Flexibility: You can have one security policy for SELECT statements, another for INSERT statements, and still others for UPDATE and DELETE statements. For example, you might want to enable Human Resources clerks to have SELECT privileges for all employee records in their division, but to update only salaries for those employees in their division whose last names begin with A through F. Furthermore, you can create multiple policies for each table, view, or synonym.

Comments

Post a Comment

Popular posts from this blog

Introduction to Encryption

Image
What is Encryption? Encryption is like sending secret messages between parties; if someone tries to pry without the proper keys, they won't be able to understand the message. In other words, it is the process of locking up information using cryptography (Cryptography is both the practice and the study of hiding information.) Definition:  ‘ The Process of converting plain text into cipher text, something that appears to be random and meaningless ’ is called as the encryption. Process of converting cipher text back into original text is called as decryption . Terminology Original message is called as plain text/clear text.   Encrypted message is called as cipher text/encrypted text.  A Key which is a secret like a password which is used to encrypt and decrypt information.  Ciphers are the specific algorithms which are used to encrypt and decrypt data. A cipher is series of well-defined steps that can be followed as a procedure to encrypt and decrypt m
Read more

Cross-Site Request Forgery protection in web applications via Double Submit Cookies Patterns

Image
Double submission of cookies is another well-known method to block CSRF. Similar to using unique tokens, random tokens are assigned to both a cookie and a request parameter. In double-submitted cookie pattern, two cookies (for the session and for the CSRF token) are stored in the browser. This pattern is also called as Stateless CSRF Defense since the server site does not have to save this value in any way, thus avoiding server side state. In our previous method, we stored CSRF token values on the server side (text file). But here we don't do it. When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session id. The site then requires that every transaction request include this random value as a hidden form value (or other request parameter). A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin
Read more

How to do a Phishing attack on Facebook?

Image
This is a Step by step tutorial to make an undetectable Facebook phishing site. Step 1: Download page source Go to https://www.facebook.com Right click on the blank area -> Click Save As When dialog box appears select ‘Webpage, complete’ as Save as type -> Click Save Step 2: Edit “Facebook - Log In or Sign Up.html” file and rename it. Open ‘Facebook - Log In or Sign Up.html’ file with notepad or Dreamweaver. Remove all the ajax codes. (You can download HTML file which removed all ajax codes form here https://github.com/nimeshikaranasinghe/Facebook-Phisihing.git   ) Search for login action (Press Ctrl + F -> type ‘ action= ’ -> Click Find Next) Replace the highlighted part (as in the following screenshot) with getDetails.php Save the file as index.html Step 3: Create getDetails.php Open a notepad. Type the following code <?php             $username = $_POS
Read more