What are Call Back Functions in JavaScript

Callback functions often seem quite confusing or complicated at first, but if we take a look under the hood we’ll find that they’re fairly straightforward. The chances are that you’ve already used them.

Callbacks are typically used to run a piece of code after a certain event has happened. Whether this event is mouse-clicking on a link, data being written to a database, or just another piece of code finishing executing isn’t important, as it could be just about anything. A callback function itself is typically an anonymous function—a function declared without a name—that’s passed directly into the receiving function as a parameter. Don’t worry if this just seems like jargon right now; we’ll look at code examples soon and you’ll see how easy it actually is!

Running a Callback Function

Simply declare a new function called setTimeout that accepts the parameters callback and delay; the names aren’t important—they can be anything you want. The following code snippet demonstrates this (note that you’ll not be able to run this in a JavaScript console):

The callback parameter is expected to be a function, which can be invoked at a specific

point in the setTimeout function 1. In this case you’re passing it a simple anonymous function 2 that will write a message to the console log. So when the setTimeout function deems it appropriate, it will invoke the callback and the message will be logged to the console. That’s not so difficult, is it?

If JavaScript is your first programming language you’ll have no idea how weird this concept of passing anonymous functions around looks to those coming in from different backgrounds. But the ability to operate like this is one of JavaScript’s great strengths. Typically you won’t generally look inside the functions running the callbacks,whether it’s setTimeout, jQuery’s ready, or Node’s createServer. The documentation for all of these will tell you what the expected parameters are, and also what parameters it may return.

CallBack Scope

Something to bear in mind when passing anonymous functions around like this is that the callback doesn’t inherit the scope of the function it’s passed into. The callback function isn’t declared inside the destination function, merely invoked from it. A callback function inherits the scope in which it’s defined. 

Let’s understand this with the idea of scope circles and look at this visually in figure

Here you can see that the callback has its own local scope inside the global scope, as that’s where requestB is defined. This is all very well and good if your callback will only need access to its inherited scope, but what if you want it to be smarter? What if you want to use data from your asynchronous function in your callback? Currently the example callback function has a dollar amount hard-coded into it, but what if you want that value to be dynamic, to be a variable? Assuming this value is set in the setTimeout function, how do you get it into the callback? You could save it to the global scope, but as you know by now this would be bad. So you need to pass it as a parameter into the callback function. This should give you something like the scope circles shown in figure

This code snippet will output the same message to the console that you’ve already seen. The big difference now is that the value of dollars is being set in the setTimeout function and being passed to the callback.

ARP Cache Poisoning of Switched Network

In my previous article Sniffing a switched network i gave an introduction, on how a switched networked can be sniffed and what are the popular different techniques. In this article i am explaining one of the techniques i discussed in my previous  article.

The ARP Process

The two main types of packet addressing are at layers 2 and 3 of the OSI model. These layer 2 addresses, or MAC addresses, are used in conjunction with whichever layer 3 addressing system you are using. In this book, in accordance with industry-standard terminology, I refer to the layer 3 addressing system as the IP addressing system. All devices on a network communicate with each other on layer 3 using IP addresses. Because switches operate on layer 2 of the OSI model, they are

cognizant of only layer 2 MAC addresses, so devices must be able to include this information in packets they construct. When a MAC address is not known, it must be obtained using the known layer 3 IP addresses to be able to forward traffic to the appropriate device. This translation process is done through the layer 2 protocol ARP. The ARP process, for computers connected to Ethernet networks, begins when one computer wishes to communicate with another. The transmitting computer first checks its ARP cache to see if it already has the MAC address associated with the IP address of the destination computer. If it does not, it sends an ARP request to the data link layer broadcast address FF:FF:FF:FF:FF:FF, as discussed in Chapter 1. As a broadcast packet, this packet is received by every computer on that particular Ethernet segment. The packet basically asks, “Which IP address owns the XX:XX:XX:XX:XX:XX MAC address?”

Devices without the destination computer’s IP address simply discard this ARP request. The destination machine replies to the packet with its MAC address via an ARP reply. At this point, the original transmitting computer now has the data link layer addressing information it needs to communicate with the remote computer, and it stores that information in its ARP cache for

fast retrieval.

How ARP Cache Poisoning Works

ARP cache poisoning, sometimes called ARP spoofing, is the process of sending ARP messages to an Ethernet switch or router with fake MAC (layer 2) addresses in order to intercept the traffic of another computer. Figure illustrates this setup.

ARP cache poisoning is an advanced form of tapping into the wire on a switched network. It is commonly used by attackers to send falsely addressed packets to client systems in order to intercept certain traffic or cause denialof- service (DoS) attacks on a target. However, it can also be a legitimate way to capture the packets of a target machine on a switched network.

Tapping out a Switched Network

In my previous article Sniffing a switched network i gave an introduction, on how a switched networked can be sniffed and what are the popular different techniques. In this article i am explaining one of the techniques i discussed in my previous  article.

A network tap is a hardware device that you can place between two points on your cabling system in order to capture the packets between those two points. As with hubbing out, you place a piece of hardware on the network that allows you to capture the packets you need. The difference is that rather

than using a hub, you use a specialized piece of hardware designed for network analysis. There are two primary types of network taps: aggregated and non aggregated. Both types of taps sit in between two devices in order to sniff the communications. The primary difference between an aggregated tap and a non aggregated tap is that the non aggregated tap has four ports and the aggregated tap only has three ports. Taps also typically require a power connection, although some include batteries for brief stints of packet sniffing without the need to plug into a power receptacle.

Aggregated Taps

The aggregated tap is the simplest to use. It has only one physical monitor port for sniffing bidirectional traffic. To capture all traffic to and from a single computer plugged into a switch using an aggregated tap, follow these steps:

1. Unplug the computer from the switch.
2.  Plug one end of a network cable into the computer, and plug the other end into the tap’s “in” port.
3.  Plug one end of another network cable into the tap’s “out” port, and plug the other end into the network switch.
4. Plug one end of a final cable into the tap’s “monitor” port, and plug the other end into the computer that is acting as your sniffer.

The aggregated tap should be connected as shown in Figure. At this point, your sniffer should be capturing all traffic in and out of the computer you’ve plugged into the tap.

Non aggregated Taps

The nonaggregated tap is slightly more complex than the aggregated type, but it allows a bit more flexibility when capturing traffic. Instead of a single monitor port that can be used to listen to bidirectional communication, the nonaggregated type has two monitor ports. One monitor port is used for sniffing traffic in one direction (from the computer connected to the tap), and the other monitor port is used for sniffing traffic in the other direction (to the computer connected to the tap).

To capture all traffic to and from a single computer plugged into a switch,

follow these steps:

1. Unplug the computer from the switch.
2. Plug one end of a network cable into the computer, and plug the other end into the tap’s “in” port.
3. Plug one end of another network cable into the tap’s “out” port, and plug the other end into the network switch.
4. Plug one end of a third network cable into the tap’s “monitor A” port, and plug the other end into one NIC on the computer that is acting as your sniffer.
5.  Plug one end of a final cable into the tap’s “monitor B” port, and plug the other end into a second NIC on the computer that is acting as your sniffer.

The nonaggregated tap should be connected as shown in Figure

Choosing a Network Tap

Given the difference between these two types of taps, which one is better? In most situations, aggregated taps are preferred, because they require less cabling and don’t need two NICs on your sniffer computer. However, in situations where you are capturing a high volume of traffic or care about traffic going in only one direction, nonaggregated taps are beneficial.

Hubbing a Swiched Network

In my previous article Sniffing a switched network i gave an introduction, on how a switched networked can be sniffed and what are the popular different techniques. In this article i am explaining one of the techniques i discussed in my previous  article.

Another way to capture the traffic through a target device on a switched network is by hubbing out. This is a technique by which you segment the target device and your analyser system on the same network segment by plugging them directly into a hub. Many people think of hubbing out as cheating, but it’s really a perfect solution in situations where you can’t perform port mirroring but still have physical access to the switch the target device is plugged into.

To hub out, all you need is a hub and a few network cables. Once you

have your hardware, connect it as follows:

1. Go to the switch the target device resides on and unplug the target fro the network.

1. Plug the target’s network cable into your hub.

1. Plug in another cable that connects your analyzer to the hub.

1. Plug in a network cable from your hub to the network switch to connect the hub to the network.

Now you have basically put the target device and your analyzer in the same broadcast domain, and all traffic from your target device will be broadcast so that the analyzer can capture those packets, as illustrated in Figure

In most situations, hubbing out will reduce the duplex of the target device from full to half. While this method isn’t the cleanest way to tap into the wire, it’s sometimes your only option when a switch does not support port mirroring. But keep in mind that your hub will also require a power

connection, which can be difficult to find in some instances.

Finding True Hub

When hubbing out, be sure that you’re using a true hub and not a falsely labeled switch. Several networking hardware vendors have a bad habit of marketing and selling a device as a hub when it actually functions as a low-level switch. If you aren’t working with a proven, tested hub, you will see only your own traffic, not that of the target device. When you find a hub, test it to make sure it really is a hub. If it is, it’s a keeper! The best way to determine whether or not a device is a true hub is to hook up a pair of computers to it and see if one computer can sniff traffic between the other computer

and various other devices on the network, such as another computer or a printer. If so, that’s a true hub. Since hubs are so antiquated, they are not really mass-produced anymore. It’s almost impossible to buy a true hub off the shelf, so you’ll need to be creative in order to find one.  eBay can be a good source of hubs, but be wary, as you may run into the same issue with switches mislabeled as hubs.

Port Mirroring a Switched Network

In my previous article Sniffing a switched network i gave an introduction, on how a switched networked can be sniffed and what are the popular different techniques. In this article i am explaining one of the techniques i discussed in my previous article.

Port mirroring, or port spanning, is perhaps the easiest way to capture the traffic from a target device on a switched network. In this type of setup, you must have access to the command-line or web-management interface of the switch on which the target computer is located. Also, the switch must support port mirroring and have an empty port into which you can plug your sniffer. To enable port mirroring, you issue a command that forces the switch to copy all traffic on one port to another port. For instance, to capture the traffic from a device on port 3 of a switch, you could simply plug your analyzer into port 4 and mirror port 3 to port 4, allowing you to see all traffic transmitted and received by your target device. Figure illustrates port mirroring.

The way that you set up port mirroring depends on the manufacturer of your switch. For most switches, you’ll need to log in to a command-line interface and enter the port mirroring command. 

When port mirroring, be aware of the throughput of the ports you are mirroring. Some switch manufacturers allow you to mirror multiple ports to one individual port, which may be very useful when analyzing the communication between two or more devices on a single switch. However, let’s consider what will happen using some basic math. If you have a 24-port switch and you mirror 23 full-duplex 100Mbps ports to one port, you could potentially have 4,600Mbps flowing to that port. This is well beyond the physical threshold of a single port, so it could cause packet loss or network slowdowns if the traffic reached a certain level. In these situations, switches have been known to completely drop excess packets or even “pause” their internal circuitry, preventing communication altogether. Be sure that this type of situation doesn’t occur when you are trying to perform your capture.

Sniffing around a switched network

In my previous article i gave the idea of how to place a sniffer in a hub network. If you have no idea on how a hub works and how it a network with a hub can be sniffed i suggest you read my previous article Sniffing in a hub network.

But if you have the idea of how to sniff in a hub network then you can move on to this article easily.

Switches are the most common type of connection device used in modern network environments. They provide an efficient way to transport data via broadcast, unicast, and multicast traffic. As a bonus,switches allow full-duplex communication, meaning that machines can send and receive data simultaneously.Unfortunately for packet analysts, switches add a whole new level of complexity.When you connect a sniffer to a port on a switch, you can see only broadcast traffic and the traffic transmitted and received by your machine, as shown in Figure. 

There are four primary ways to capture traffic from a target device on a

switched network: 

• Port Mirroring
• Hubbing Out
• Tapping Out
• ARP Cache Poisoning

In my next few articles i will try to write these techniques in a simple manner.

Sniffing Packets in a Hubbed Network

Sniffing on a network that has hubs installed is a dream for any packet analyst.Traffic sent through a hub goes through every port connected to that hub. Therefore, to analyse the traffic running through a computer connected to a hub, all you need to do is connect a packet sniffer to an empty port on the hub. You will be able to see all communication to and from that computer, as well as all communication between any other
devices plugged into that hub. As illustrated in Figure, your visibility window is limitless when your sniffer is connected to a hub-based network.

Unfortunately for hub-based networks are pretty rare because of the headaches they cause network administrators. Because only one device can communicate at any one time, a device connected through a hub must compete for bandwidth with the other devices trying to communicate through the hub. When two or more devices communicate at the same time, packets collide, as shown in Figure 2. The result may be packet loss, and the communicating devices will compensate for that loss by re transmitting packets,which increases network congestion and collisions. As the level of traffic and number of collisions increase, devices may need to transmit a packet three or four times, decreasing network performance dramatically. It’s easy to understand why most modern networks of any size use switches. 

Intervention Library Integration With Laravel

Intervention is an image library. It is a very good library for processing images and gives a very short solution for processing images in your application. It comes with several built in functions to help you with image processing.

In this tutorial i will tell you how to integrate this amazing library with Laravel 5.2. I searched a lot but i was unable to get this knowledge at one point


so i thought to write it down.

Requirements 

In order to install this library you must have one of these two libraries  

• GD Library (>=2.0) … or …
• Imagick PHP extension (>=6.5.7)

Note:  I am assuming here that you are working in latest environment and have .

• PHP >= 5.4
• Fileinfo Extension

That's all we need to install this amazing library so far.

Getting Started  

Now to get started you first need to install this library in your project folder but to do this you must have to run this command in your project folder as in my case i am assuming that my XAMPP is in D: so the path will be

d:\xampp\htdocs\'project_name'

After coming in this folder in cmd run the following command. 

$ php composer.phar require intervention/image

 Now your composer.jsaon has been updated automatically and you are able to require the just created vendor/autoload.php file to PSR-4 autoload the librayr.The library is now installed in your current project but its not over yet. 

Intervention image has optional support for Laravel and comes  with a Service provider and Facad  intergration. The vendor/autoload.php  is included by Laravel , so you dont have to require or auto manually. Just do as i say.

After Installation go to laravel config/app.php and in there in the $providers array add this line 

Intervention\Image\ImageServiceProvider::Class

 Add the facade of thus package to $aliases array in the same file

'Image' => Intervention\Image\Facaes\Image::class

Now the image class will be autoloaded by laravel 

Difference Between Hub and Switch

There is a common misunderstanding in these two hardware pieces which are commonly doing the dirty work of networking in almost every network in this artcile i will describe the differnce between these two.

Hubs

 A hub is generally a box with multiple ports. They range from very small to large depending on the requirement. Because hubs can generate a lot of unnecessary network traffic and are

capable of operating only in half-duplex mode (they cannot send and receive

data at the same time), you won’t typically see them used in most modern or

high-density networks (switches are used instead). 

A hub is no more than a repeating device that operates on the physical

layer of the OSI model. It takes packets sent from one port and transmits

(repeats) them to every other port on the device. For example, if a computer

on port 1 of a 4-port hub needs to send data to a computer on port 2, the

hub sends those packets to ports 1, 2, 3, and 4. The clients connected to

ports 3 and 4 examine the destination Media Access Control (MAC) address

field in the Ethernet header of the packet, and they see that the packet is not

for them, so they drop (discard) the packet. Figure 1-5 illustrates an example

in which computer A is transmitting data to computer B. When computer A

sends this data, all computers connected to the hub receive it. Only computer B

actually accepts the data; the other computers discard it.

The best alternatives to hubs in production and high-density networks

are switches, which are full-duplex devices that can send and receive data

synchronously.

Switches

Like a hub, a switch is designed to repeat packets. However, unlike a hub,

rather than broadcasting data to every port, a switch sends data to only the

computer for which the data is intended.

Switches also offer advanced functionality when it comes to handling

transmitted packets. In order to be able to communicate directly with specific

devices, switches must be able to uniquely identify devices based on their MAC

addresses, which means that they must operate on the data link layer of the

OSI model.

Switches store the layer 2 address of every connected device in a CAM

table, which acts as a kind of traffic cop. When a packet is transmitted, the

switch reads the layer 2 header information in the packet and, using the CAM

table as reference, determines to which port(s) to send the packet. Switches

send packets only to specific ports, thus greatly reducing network traffic.

Figure 1-7 illustrates traffic flow through a switch. In this figure, computer

A is sending data to only the intended recipient: computer B. Multiple

conversations can happen on the network at the same time, but information

is communicated directly between the switch and intended recipient, not

between the switch and all connected computers.

Mail Verification Using Laravel 5

In this article i will be showing you how to send a verification email to a user's entered email address. If you listen this process for the first time it sounds like a nightmare but actually if you have a little concept of MVC and laravel architecture then you can easily understand this article and can get a fully automated verification email service on your laravel application.So lets get started.

Requirements

So in order to do this we will have to create just two fields in the sign up form in addition to the fields that are already in the most users table i.e username,email,password,confirm password etc. So first we need a field with boolean data type in order to keep track that whether a user has activated its account or not. This field will be set to false by default.

The second field that we require is a confirmation_code field and its data type is string. When a user registers a new account we generate a random string and then  store this generated field in the database an email will be sent to the user asking him to confirm his/her account by following a link that we will define in our /app/http/routes.php. When a user will click on this link we will take this information we compile it in our code match with our string and then complete the process.

The code i am writing below is of a very simple user's table.  

use Illuminate\Database\Schema\Blueprint;

use Illuminate\Database\Migrations\Migration;
class CreateUsersTable extends Migration{    

/**     

* Run the migrations.     

*     

* 

@return void     

*/    

public function up()    {        

Schema::create('users', function (Blueprint $table) {            

$table->;increments('id');            

$table->;string('name');            

$table->;string('email')->;unique();            

$table->;string('password', 60);            

$table->;boolean('confirmed')->;default(0);            

$table->;string('confirmation_code')->nullable();            

$table->rememberToken();            

$table->timestamps();        

});    

}
    

/**     

* Reverse the migrations.     

*     

* @return void     

*/    

public function down()    {        

Schema::drop('users');    

}}

User Registration

Now that the user table is set up we can begin adding our registration functionality. This is same as the normal procedure when the user submits we validate and we store. The real story comes after that when we have to generate a random string that is going to be used as the confirmation_code for the user. We can generate the random string by using a helper function of laravel str_random() in the argument give the number for the length of the generated string. With the confirmation code generated we now have all the information we need to create user. 

Note  If you are using mass assignment with User::create(), You need to set the $fillable property on your user model to contain username, email, password and confirmation code.

Now once the user is created we need to send him his confirmation email. We will use laravel's  Mail::send()   and create very basic email template that will tale the confirmation_code  and output a link to the confirmation URL that the user needs to visit. 

Code For Storing User and Sending Mail 

This code will be written in the controller in my case the controller name is RegistrationController  

namespace App\Http\Controllers;
use Illuminate\Http\Request;
use App\Http\Requests;

use App\Http\Controllers\Controller;

use Illuminate\Support\Facades\Mail;

use Illuminate\Support\Facades\Redirect;

use Input;

use Validator;

use App\User;

use Hash;


class RegistrationController extends Controller{    

public function send_mail(){
        $auth = [                

'name' =>'required|min:6',                

'email' =>'required|email|unique:users',                

'password' =>'required|confirmed|min:6',                

'password_confirmation' =>'required|min:6'
 ];        

// Getting Input        

$input = Input::all();

// Performing Validation        

$validator = Validator::make($input, $auth);        

if($validator->fails())

{            

return Redirect::back()->withInput()->withErrors($validator);        }        

// Generating random string        

$confirmation_code = str_random(32);


//Creating User          

$user = User::create([
'name' => Input::get('name'),             

'email' => Input::get('email'),             

'password' => Hash::make(Input::get('password')),             

'confirmation_code' =>  $confirmation_code,
         ]);
 // Sending Mail        

Mail::send('email.verify', array('confirmation_code'=>$confirmation_code), function($message) {$message->to(Input::get('email'), Input::get('username'))->subject('Verify your email address'); });
 // Printing Message
        echo "";
        return view('welcome');

    }

}

The simple verification email using blade is 

<html>
<html lang="en-US">
<head>
 <meta charset="utf-8">
 </head> 
<body>
 <h2>Verify Your Email Address</h2>

<div>
    Thanks for creating an account with the verification demo app.
    Please follow the link below to verify your email address
    {{ URL::to('register/verify/' . $confirmation_code) }}.<br>

<div>

<body>
<html>


User Confirmation

To complete the confirmation process the user must follow the lick that is send to them in their mail. So the route of our link will be such like that

Route::post('register/verify','RegistrationController@send_mail');

Route::get('register/verify/{confirmationCode}', 

[    'as' =>'confirmation_path',    

'uses' => 'RegistrationController@confirm']);

Now we need to define a method in the controller which will do a couple of important things. First we need to find the user to which this confirmation code belongs. If no confirmation code is included or the code does not belong to any user then we will redirect back to home page.

If a user is found then we his/her confirmed field to true and set their confirmation_code to null. This is done so that on the off chance the same code is generated and given to two separate users then as long as the first user verified their email address they will no longer have this code set and no problems will arise.

// Confirmation Code
   public function confirm($confirmation_code)   {       
if( ! $confirmation_code)       
{           
throw new InvalidConfirmationCodeException;       
}
$user = User::whereConfirmationCode($confirmation_code)->first();
if ( ! $user)       
{           
throw new InvalidConfirmationCodeException;       
}
$user->confirmed = 1;       
$user->confirmation_code = null;       
$user->save();
       echo "";
       return view('welcome');   }
Thats all there is for email verification :)


Feel free to throw any query in comments :).

Linux File System

The Linux file system is the structure in which all the information on your computer is stored. In fact, one of the defining properties of the
UNIX systems on which Linux is based is that nearly everything you need to identify on your system (data, commands,symbolic links, devices directories) is represented by items in the file systems. Knowing where things are and understanding hoe to get around fliest from shell are critical skills in Linux.




In Linux the files are organized within hierarchy of directories .Each directory can have files ror other directories. You can go to another directory or file by using either the full the full path (/home/fahad/myfile.txt) or a relative path  (for example /home/fahad were your current directory , you could simply refer to the file as myfile.txt.

The Linux file system looks like a tree upside-down. At the very top is the root directory  (do not confuse with the root user) it is represented by a single slash(/). This is illustrated in the figure below.

Fig (1)

These Linux directories may interest you

1. /bin -- Contains common Linuxx user commands, e.g ls,sort,date and chmod
2. /boot -- Has the bootable Linux kernel and boot loader configuration (GRUB).
3. /dev -- Contains files representing access points to devices on your systems. These can be of different types e.g  terminal devices (tty*), floppy disks (fd*), hard disks (hd*).
4. /etc -- Contains administrative configuration files. These files can be edited.
5. /home -- Contains directories assigned to each regular use with a log in attempt.
6. /media -- Provides a standard location for automounting devices. (removable media in particular).
7. /lib -- Contains shared libraries needed by application in /bin/ and /sbin to boot the system.
8. /mnt -- A common mount point  for many devices before it was supplanted by the standard /media directory. Some bootable Linux systems still use this directory.    
9. /misc -- A directory sometimes used to auto mount file systems upon request.
10. /opt -- Directory structure available to store add-on application software.
11. /proc -- Contains information about system resources.
12. /root -- Represents the user's home directory. The home directory for root does not reside beneath  /home for security reasons.
13. /sbin -- Contains administrative commands on daemon processess.
14. /tmp -- Contains temporary files used by applications.
15. /usr -- Contains user documentation games,graphical files (X11), libraries (lib) and variety of other commands..
16. /var -- Contains directories of data used by various applications.   

CSRF(Concept &Scope)XSRF, Session Riding & Confused Deputy Attacks

Cross Site Request forgery (CSRF) attack occur when a malicious web site causes a user's web browser to preform an unwanted action on site which is trusted by the user and important credentials are being held by user at that site. These attacks are easy to prevent and easy to exploit.  Cross Site Request Forgery attacks are also known  as the Cross Site Reference Forgery (XSRF), Session Riding and Confused Deputy Attacks. I am using CSRF because it is the most commonly used term.

CSRF attacks are successful when an attacker can cause a user's browser to perform an unwanted action on another site which is the trusted user site. For this action to be successful  the user must be capable of performing this action. CSRF attacks are usually as powerful as a user. Means the more the user have access or privilege power on a web application the more powerful a successful attack will be. CSRF attacks are successful nearly against every site that is using implicit authentication. does not explicitly protect itself from CSRF attack.

CSRF Explanation Through Figs

Fig (1)

Fig (2)

Fig (3)

Authentication and CSRF

CSRF attacks most commonly exploit the authentication mechanisms if targeted sites. The root of the problem is that Web authentication normally assures site that a request came from a certain user's browser but it does not ensure that the user actually requested or authorised the request.

Explanation wit the help of Example

Suppose that the V visits a trusted site S when V visits this site the server gives V browser a Pseudo random Session Identifier SID  this SID is used by the server of S to identify that the user is V. when ever a request will be made by the V browser the browser will append this SID with the request and the S will understand that its V.

Now lets suppose that the V visits a malicious site with the same browser and there is a malicious Javascript code in that site which makes a HTTP request to the site S now the browser of V will append that SID  with the request as the request is being made to the trusted so when this request reaches the S it will be interpreted as the  request from V and it will be a successful CSRF attack. 

CSRF and SSL

Alternatively the V may use Client Side SSL certificate but it will result in the same problem because the browser will helpfully use the certificate  to carry out request to S's site . Similarly if the V authenticates by his IP address CSRF attack would be possible.