Monday, August 25, 2014

Oracle PL/SQL functions and procedures

PL/SQL Function

DECLARE
   a number;
   b number;
   c number;
FUNCTION findMax(x IN number, y IN number)
RETURN number
IS
    z number;
BEGIN
   IF x > y THEN
      z:= x;
   ELSE
      Z:= y;
   END IF;

   RETURN z;
EXCEPTION
   WHEN NO_DATA_FOUND THEN
      DBMS_OUTPUT.PUT_LINE('No such employee: ' || Emp_number);

END;

Calling a function from another function/procedure
BEGIN
   a:= 23;
   b:= 45;
   c := findMax(a, b);
   dbms_output.put_line(' Maximum of (23,45): ' || c);

END;

PL/SQL Procedure

DECLARE
   a number;
   b number;
   c number;

PROCEDURE findMin(x IN number, y IN number, z OUT number) IS
BEGIN
   IF x < y THEN
      z:= x;
   ELSE
      z:= y;
   END IF;
EXCEPTION
   WHEN NO_DATA_FOUND THEN
      DBMS_OUTPUT.PUT_LINE('No such employee: ' || Emp_number);
END;

Calling a procedure
  1. From the SQL prompt.
 EXECUTE [or EXEC] procedure_name;
  1. Within another procedure – simply use the procedure name.
 procedure_name;

Friday, August 22, 2014

Rule Engine

Drools - steps to use it in a typical program
  1. create working memory
  2. asset objects (insert into working memory)
  3. fire all rules
  4. retrieve objects
Rule attributes
- name
- group
- description
- priority

Rules
  1. Production rules (inference rules) - if x, then y
  2. Reaction Riles - wait for a set of events
  3. Stateful
Rete algorithm (Forward Chaining)
  1. iterate through antecedants
  2. each time an antecedant is matched, add knowledge of consequence
  3. do this until goal is reached
Guvnor - Business rules management system

RESTful WebServices - API Keys


Http methods
Get (read), header, post(create), put(update), trace, delete(delete)

API keys are used for
  • Limit API usage, security

API flow sequence
  • Log in to PayPal developer site - register your application by logging into the PayPal Developer site using a PayPal account, and by going to the Applications tab. 
  • PayPal provides a client_id and secret - You will be issued a set of test credentials (‘client_id’ and ‘secret’) that you can use to authenticate your API calls using the OAuth 2.0 protocol.
  • Client calls /token endpoint with client_id and secret_key - You then obtain an access token for your application by sending a request to the ‘/v1/oauth2/token’ endpoint. You need to authenticate your access token request (using HTTP Basic Auth) with your application credentials (client_id and secret_key) obtained as described above. The ‘client_id’ and ‘secret’ becomes your user-id and password in HTTP Basic Auth.  If you’re using cURL, you can pass the client_id and secret as -u ":"
  • PayPal returns the access token - PayPal, acting as the “authorization server”, verifies your application credentials and returns an access token. The specific kind of access token that PayPal provides is a “Bearer Token”. PayPal also provides the token type in the response, which indicates the type as Bearer.
  • Client calls PayPal Rest API with access token - When you make the API calls, make request by adding the access token in the ‘Authorization’ header using the following syntax (as defined in the OAuth 2.0 protocol):
Authorization: {tokenType} {accessToken}
    Example: Authorization: Bearer EEwJ6tF9x5...4599F

    • Access token validity and expiration - PayPal-issued access tokens can be used to access all the REST API endpoints. These tokens have a finite lifetime and you must write code to detect when an access token expires. You can do this either by keeping track of the ‘expires_in’ value returned in the response from the token request (the value is expressed in seconds), or handle the error response (401 Unauthorized) from the API endpoint when an expired token is detected.
    link: https://developer.paypal.com/docs/integration/direct/paypal-oauth2/

    Common Web Security vulnerabilities


      Principle to remember: Filter input escape output
      SQL injection (user input is not filtered for special characters) 

      Example:
      1. A form is displayed on a web application that contains some text fields
      2. These text fields data are not validated on the client/server side so it lets any data in
      3. The data entered is directly used in building an SQL query
      4. A malicious user enters some bad data in the text field which contains an executable SQL statement to corrupt the database or display unintended results
      5. So, instead of executing "SELECT * FROM products WHERE id_product=$id_product", the application executes "SELECT * FROM products WHERE id_product=$id_product UNION Select * from USERS"
      Cross Site Scripting (code injection by malicious to pages used by real users) - this happens when developers do not check the input and let arbitrary data in to the database. Then, this arbitrary data (such as a javascript embedded in script tag)  is displayed on the web page. When a user performs an action on the web page, sensitive data such as sessionId or personal data is sent unknowingly to the malicious web site. This is very similar to SQL injection but instead of sending SQLs in text fields, a text containing script tag is sent to the server side to be stored in the database only to be displayed later.

      Example:
      1. A real website displays a form containing name etc.
      2. Since there is a bug in the server side code, it lets any text to be entered in the text field
      3. A malicious user enters a text which contains some javascript embedded in script tags
      4. The server side application persists this data into database
      5. The application has a web page that displays a list of all names
      6. When a real user retrieves this webpage, it displays the names but also executes javascript
      7. When the user submits or performs some action on this webpage, it sends cookies etc to a malicious website.
      CORS - Cross Origin Resource Sharing

      CSRF - Cross Site Request Forgery
      This attack happens if a user does not logout from a good website. Say for example, a good website transfers money using this URL: amount=100.00&routingNumber=1234&account=9876

      A evil website may have HTML code with hidden input fields for amount, routing number and account. It may have an image that says "Win MoneY" which when clicked will submit the hidden form fields to the URL for the good website. Since the user is already authenticated and forgot to logoff, the transaction will be executed without the user knowing about it.

      One solution is to use the Synchronizer Token Pattern. This solution is to ensure that each request requires, in addition to our session cookie, a randomly generated token as an HTTP parameter. When a request is submitted, the server must look up the expected value for the parameter and compare it against the actual value in the request. If the values do not match, the request should fail.

      We can relax the expectations to only require the token for each HTTP request that updates state. This can be safely done since the same origin policy ensures the evil site cannot read the response. Additionally, we do not want to include the random token in HTTP GET as this can cause the tokens to be leaked. So, the new URL looks like this:
      amount=100.00&routingNumber=1234&account=9876&_csrf=

      You will notice that we added the _csrf parameter with a random value. Now the evil website will not be able to guess the correct value for the _csrf parameter (which must be explicitly provided on the evil website) and the transfer will fail when the server compares the actual token to the expected token.

      https://docs.spring.io/spring-security/site/docs/current/reference/html/csrf.html

      If you are only creating a service that is used by non-browser clients, you will likely want to disable CSRF protection.

      Improper identity and access management
      - forget password mgmt features

      Not implementing API keys for clients

      Denial of service
      - flooding a website/webservice with requests so that legitimate users can't use it

      Wednesday, August 06, 2014

      Configuring SSL offloading (LB-OHS-WL)

      LB (F5-SSL) to WL(http) plugin to WL cluster(http)

      • Sticky sessions is default
      • SSL ends at LB
      • In F5, I needed to configure a header to be passed with the requests called WL-Proxy-SSL and set the value to true (WL-Proxy-SSL: true)
      • Cockie name goes in the plugin properties (JSESSIONID by default) and deployment descriptor
      • WLProxySSLPassThrough should be set to ON, so that the OHS proxy/plug-in will pass the WL-Proxy-SSL header on to WebLogic Server
      • Configure the Adminserver so that it would acknowledge the proxy plugin headers.  This field is titled "WebLogic - Plug-In Enabled" and can be found on the page Configuration->General in the Advanced section