Securing and Sharing Personal Files Over The Internet

makeshiftklipInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 4 χρόνια και 8 μέρες)

88 εμφανίσεις

Software System Laboratory

Department of Electrical Engineering

Technion
-

Israel Institute of Technology










Securing and Sharing Personal Files

Over The Internet

(Content Server Security)








By

Amihay Schwarz




Instructor

Viktor Kulikov












March

2007








1

INTRODUCTION

................................
................................
............................

4

2

APPLICATION SECURITY
................................
................................
...........

5

3

APPLICATION HIGH LEV
EL DESIGN

................................
......................

8

3.1

Application Server

................................
................................
................................
...........
10

3.1.1

Applicable classes

................................
................................
...............................

10

3.1.2

Data access classes
................................
................................
.............................

12

3.2

The Proxies
................................
................................
................................
.........................
14

3.2.1

General

................................
................................
................................
................................

14

3.2.2

Commercial aspects

................................
................................
.........................

14

3.2.3

Content Web Site

................................
................................
................................
..

14

4

.NET REMOTING

................................
................................
.........................

16

4.1

How does it work

................................
................................
................................
..............
16

4.2

Trans port channels

................................
................................
................................
..........
17

4.2.1

Transport

channel security

................................
................................
..

17

4.3

Code securely
................................
................................
................................
.....................
18

5

SECURITY

19

5.1

Content Web Site
................................
................................
................................
..............
19

5.1.1

Gate keeper

................................
................................
................................
......................

19

5.1.2

Secure Communications

................................
................................
..........

19

5.1.3

Authentication

................................
................................
................................
............

21

5.1.4

Authorizat ion
................................
................................
................................
................

22

5.2

Application server

................................
................................
................................
............
22

5.2.1

Gate keeper

................................
................................
................................
......................

22

5.2.2

Secure Communications

................................
................................
..........

23

5.2.3

Authentication

................................
................................
................................
............

23

5.2.4

Authorizat ion
................................
................................
................................
................

23

5.3

Data Base server

................................
................................
................................
...............
23

5.3.1

Gate keeper

................................
................................
................................
......................

23

5.3.2

Secure Communications

................................
................................
..........

23

5.3.3

Authentication

................................
................................
................................
............

23

5.3.4

Authorizat ion
................................
................................
................................
................

23

6

U.CS DIAGRAMS
................................
................................
.........................

24

6.1

Clie
nt connection negoti ation
................................
................................
........................
24

6.2

Client accessing web server

................................
................................
...........................
25

6.3

New Client Registrati on
................................
................................
................................
..
26

6.4

Files managing
................................
................................
................................
...................
27

6.4.1

Uploading fil
es

................................
................................
................................
..........

27

6.4.2

Delet ing a file

................................
................................
................................
..............

28

6.4.3

Downloading a file

................................
................................
............................

29

6.4.4

Send file download invitation
................................
........................

30

6.4.5

Download a file from a friend
................................
.......................

31



1

Introduction

The fast rate of growth in information
compels

us to find ways to store and share our
files, sometimes sensitive files, with others.


The most comfort way 2day to share files is over the Internet. But the int
ernet
conceals

a lot of securities holes. One's sensitive information may
reach

unwanted
hands.


This Project gives us the following solution:

1.

One can store his files on a content server.

2.

One can access his files from anywhere and anytime.

3.

One can grant
pe
rmission

to others to fetch his files.

4.

Only
permi
tted

persons can
fetch
one's files.

5.

The storing and sharing process will be secured.


This project is also taking into account the commercial aspect and provides
commercials solutions.

2


Application S
ecurity

I used
traditional

security

mythologies
, with the help of Microsoft technology
in order

to give an answer to the
security

problem that we are facing in the internet.


The most
important

methodology

is the "3
layer

architectural
"
, witch giv
e
s

the
maximum s
ecurity to the different entities of the solution.

This architectural
design

divides the solution to 3 main modules and provides the
maximum security to each one.

The three modules are:



Proxies
, witch connected to the Internet and host the web application
s



Application layer
, witch runs the business logic



Data
-
Base.




Each
layer is protected by a Gatekeeper that controls the access to the layer.


The solution is making use of three key security concepts:

1.

Authentication
. Positively identifying
the clients
of the application.


2.

Authorization
. Defining what authenticated clients are allowed to see and do
within the application.

3.

Secure Communications
. Ensuring that messages remain private and
unaltered as they cross networks.

4.

Gate keepers
.

Ensuring
that the n
etwork Entities can be accessed only form
allowed network elements.



There are a number of overarching principles that apply in the
implementation
. The following
summarizes these principles:



Adopt the principle of least privilege
. Processes that run scri
pt or execute code
should run under a least privileged account to limit the potential damage that can be
done if the process is compromised. If a malicious user manages to inject code into a
server process, the privileges granted to that process determine
to a large degree the
types of operations the user is able to perform. Code that requires additional trust
(and raised privileges) should be isolated within separate processes.

The ASP.NET team made a conscious decision to run the ASP.NET account with lea
st
privileges.



Use defense in depth
. Place check points within each of the layers and subsystems
within your application. The check points are the gatekeepers that ensure that only
authenticated and authorized users are able to access the next downstream
layer.



Don't trust user input
. Applications should thoroughly validate all user input before
performing operations with that input. The validation may include filtering out special
characters. This preventive measure protects the application against accid
ental misuse
or deliberate attacks by people who are attempting to inject malicious commands into
the system. Common examples include SQL injection attacks, cross
-
site scripting
attacks, and buffer overflow.



Use secure defaults
. A common practice among de
velopers is to use reduced
security settings, simply to make an application work. If your application demands
features that force you to reduce or change default security settings, test the effects
and understand the implications before making the change.



Don't rely on security by obscurity
. Trying to hide secrets by using misleading
variable names or storing them in odd file locations does not provide security. In a
game of hide
-
and
-
seek, it's better to use platform features or proven techniques for
secur
ing your data.



Check at the gate
. You don't always need to flow a user's security context to the
back end for authorization checks. Often, in a distributed system, this is not the best
choice. Checking the client at the gate refers to authorizing the user

at the first point
of authentication (for example, within the Web application on the Web server), and
determining which resources and operations (potentially provided by downstream
services) the user should be allowed to access.

If you design solid authe
ntication and authorization strategies at the gate, you can
circumvent the need to delegate the original caller's security context all the way
through to your application's data tier.



Assume external systems are insecure
. If you don't own it, don't assume

security
is taken care of for you.



Reduce surface area
. Avoid exposing information that is not required. By doing so,
you are potentially opening doors that can lead to additional vulnerabilities. Also,
handle errors gracefully; don't expose any more inf
ormation than is required when
returning an error message to the end user.



Fail to a secure mode
. If your application fails, make sure it does not leave sensitive
data unprotected. Also, do not provide too much detail in error messages; meaning
don't incl
ude details that could help an attacker exploit a vulnerability in your
application. Write detailed error information to the Windows event log.



Remember you are only as secure as your weakest link
. Security is a concern
across all of your application tier
s.



If you don't use it, disable it
. You can remove potential points of attack by disabling
modules and components that your application does not require. For example, if your
application doesn't use output caching, then you should disable the ASP.NET outp
ut
cache module. If a future security vulnerability is found in the module, your application
is not threatened.




3

Application High Level Design


The solution is divided to 4 entities.



Web application,
r
eceives requests from the client

and forward them t
o the
"Brain"



Application Server, that uses as the "Brain" of the solution.



Mail application, that is responsible to sending mails.



Data Base
.


The solution provides
3

interfaces

that connect the different entities
.
T
w
o

of them are
implemented by the
Appli
cation Server

(located at layer 2)

a
nd one by the
Mail
application

(located at layer
1
).
Those interfaces

driven from
MarshalByRefObject


are only defined in the
ContentIFCs

D
LL

and not implemented there (security check).

The DLL declare another

Serializab
le

class for common use.


The uses and implementation of those interfaces is done by "
.
NET Framework
Remoting" technology.


The interfaces are:

1.

FileManageIfc


store file, get files, send file…

2.

UserProvisionigIfc


Register, login, Password Recovery…

3.

Serv
iceCredentialIfc


Serializable

class that

hold
s

the service credentials that
perform the request.

4.

MailingIFC


send mail.




3.1

Application Server

The Application Server

implement
s
5 applicable classes and several Data access
classes:

3.1.1

A
pplicable classes



1.

Program


main thread load, responsible for initializing the server and client
interfaces.



2.

ServiceCredentialsManager



responsible for service authentication and
authorization.



3.

Helper


Provides several helping functions:

a.

RandomNumber()


returns rand
om number

b.

RandomString()


returns random string

c.

getMd5Hash()


md5 hashing

d.

GetPassword()


generate user password

e.

GetToken()


generate file token


4.

UserprovisioningIfcImp
-

Singletone,

Implem
ents the UserParovisioningIfc

a.

DoesUserRegister()


checks that

the user is registered to the system.

b.

Login()
-

authenticate user credentials.

c.

PasswordRecovery()


regenerate users password and mail it to the
user.

d.

Register()


reisters a new user to the system and send him a new
password.


5.

FilesManagerIfcImp


Singl
etone,
Implements the FilesManagerIfc interface.

a.

StoreFile



stores a new file or update an older one

b.

GetFile



Returns a file content to the user

c.

DeleteFile



Delete user's file

d.

GetUsersFiles



Gets all files mata
-
data of the user's file

e.

SendFile



send

a download invitation to a friend. The
method
generates

a download token and sends a mail
invitation to

the friend.

f.

GetFileByToken



download a file from a friend by the token sent by
mail. The method checks for download expiry and prevent the
download if

expired.

3.1.2

Data access
classes

The

application server uses the ContentDBDataSet class for all data access issues.




1.

Users

Data

Adapter



responsible for all user metadata.

a.

AuthenticateUser
()


Basic user authentication against the data base

b.

DeleteUser()


Delete a user from the system

c.

isUserRegistered
()


return true if the user's email is registered.

d.

UpdateUser
()


updates the users details

e.

InsertUser()


add an new user to the system


2.

Files Dat aAdapter


responsible for all files related issues.

a.

AddOrU
pdateFile2User
()


add or update file for the user.

b.

CheckIfFileExist()


cheackes whter the file axsist for the user or not.

c.

DeleteUserFile
()


deletes one of the users files.

d.

GetFileContent()


gets the file content.

e.

GetUsersFiles()


gets the metadate o
f all of the users files.


3.

Downloads Data Adapter
-

responsible for all downloads

requests

a.

InsertDownloadData()


adds a new download metadata

b.

GetDownloadExpiry()


gets the download expiry by the download
metadata , if none exist return false.

c.

DeleteDown
load()


delete a download by its metadata.

The class diagram for the classes that implements the above:



3.2

The
Proxies

3.2.1

General

The
purpose

of the
Proxies

is to:

1.

Serve requests from the client and forward it to the
application server
. They
can use any kind

of protocol, (http , wap , sip + msrp, … )

2.

Hide

the access to the
application server

from the clints.


The
Proxies

uses the
FileManageIfc and

the UserProvisionigIfc that are implemented
at
the
application

server

to serve clients request.


3.2.2

Commercial aspec
ts

Each From
-
End can implement its own commercial mythology without involving the
Application server
. This extends the concept of service oriented solution.

3.2.3

Content Web Site

The
project includes

an implementation of one
proxy
in the form of web site. The
web
site is implemented on ASP .net and includes 3 pages:

1.

Login



start page for client access

2.

Registration



register new clients

3.

Main



handles all the file manipulation.


Beside of the pages classes the site also uses 4 other class:




Helper


some gene
ral methods



ServiceCredentialMGR


manage the service (web site) credential



InterfaceMGR


manage the interfaces against the
Application Server




MessageBox


a wrapper for generation client running code for displaying
message boxes on the browser.





T
he
Mail Server job is to send mails on behalf of the
Application Server


that is on the
back end and cant sent mails.


The Mail Server implements the
MalingIfc
.



3.3

The DB

The DB has 4 tables:

1.

Users


that hold the user provisioning

2.

Files


that hold the f
iles that the users have.

3.

Downloads


that hold all granted permissions to files download.

4.

Service credential


that hold the allowed services.


DB relations



4

.Net Remoting

All of the internal entities in the solution communicate by using .net Remoting
t
echnology.


4.1

How does it work

The .net Remoting give us abstraction for RMI that we can use, first we need to define
the remote object we want to invoke. Then we connect this object to the Remoting by
the Remoting APIs. And the net abstraction does all the

work.



4.2

Transport channels

There are several transport channels:



HttpChannel
. This channel is designed to be used when you host a remote
object in
ASP.NET. This channel uses the HTTP protocol to send messages between the client
and the server.



TcpChannel
. This channel is designed to be used when you host a remote object in a
Microsoft® Windows® operating system service or other executable.

This channel
uses TCP sockets to send messages between the client and the server.



Custom channels
. A custom transport channel can use any underlying transport
protocol to send messages between the client and server. For example, a custom
channel may use
named pipes or mail slots.

I decided to use the TCPChannel because it’s the most reliable and it can be easily
secure.

4.2.1

Transport channel security


The Solution uses IPSec to secure the transport of data between the client and server.

IPSec can be used to
secure the data sent between two computers; for example, an
application server and a database server. IPSec is completely transparent to
applications as encryption, integrity, and authentication services are implemented at
the transport level. Applications

continue to communicate with one another in the
normal manner using TCP and UDP ports.

Using IPSec you can:



Provide message confidentiality by encrypting all of the data sent between two
computers.



Provide message integrity between two computers (withou
t encrypting data).



Provide mutual authentication between two computers (not users). For example,
you can help secure a database server by establishing a policy that permits
requests only from a specific client computer (for example, an application or Web

server).



Restrict which computers can communicate with one another. You can also
restrict communication to specific IP protocols and TCP/UDP ports.

4.3

Code securely


The remote object

binaries are located both in the
p
roxies

and in the back ends.


In the
p
roxies

only the interface declaration binaries are located and therefore even if
someone brake into the
p
roxies

he will not have the implementation.


Only in the back ends the
remote object

binaries contains the implementation.

(u can see the class diagram

above)


5

Security


A lot of
effort was invested in this project in order to make it secured.

One of the project goals was to assimilate Microsoft technology in
security and

work
according to it guide lines.


As stated before the solution is making use of
four

key security concepts:

a.

Gate keepers
.

Ensuring
that the network Entities can be accessed only form
allowed network elements.

b.

Secure Communications
. Ensuring that messages remain private and
unaltered as they cross networks


c.

Authentication
. Positively i
dentifying
the clients of the application.


d.

Authorization
. Defining what authenticated clients are allowed to see and do
within the application.

In the following sections I will explain how I implemented the solution according to
thus security concepts.


5.1

Content Web Site

5.1.1

Gate keeper


The content web site is on the global
internet
-

One.
Therefore

it is the most
vulnerable

entity in the solution. We most make sure that the server is blocked on all
interfaces except for the
HTTPS in which it serves its desi
gnated requests.


The Gate configuration:


In

Out

IP

All

None

Port

HTTPS (

TCP
443)

None


5.1.2

Secure Communications

All communication to the content web site
is

done by HTTPS, which is HTTP over a
secured Transport.
IIS supports TLS

-

Transport Layer Securi
ty
, as
the secured
transport protocol.

5.1.2.1

TLS

5.1.2.1.1

Description

The TLS protocol allows applications to communicate across a network in a way
designed to prevent
eavesdropping
,
tampering
, and
message forgery
. TLS provides
endpoint
authentication

and
communications privacy

over the
Internet

using
cryptography
. Typically, only the server is authenticated (i.e., its identity is ensured)
while the client remains unauthenticated; this means that the end user (whether an
individual or an
application, such as a Web browser) can be sure with whom they are
communicating. The next level of security

in which both ends of the "conversation"
are sure with whom they are communicating

is known as
mutual authentication
.
Mutual authentication requires
public key infrastructure

(PKI) deployment to clients
unle
ss
TLS
-
PSK

or
TLS
-
SRP

are used, which provide strong mutual authentication

without needing to deploy a PKI.

TLS involves three basic phases:

1.

Peer negotiation for algorithm support

2.

Public key

exchange and certificate
-
based authentication

3.

Symmetric cipher

encryption

During the first phase, the client and server negotiate cipher suites, which combine
one cipher from each of the following:



Public
-
key cryptography:
RSA
,
Diffie
-
Hellman
,
DSA




Symme
tric ciphers:
RC2
,
RC4
,
IDEA
,
DES
,
Triple DES
,
AES

or
Camellia




Cryptographic hash function
:
MD2
,
MD4
,
MD5

or
SHA


5.1.2.1.2

How it works

A TLS client and server negotiate a stateful connection by using a handshaking
procedure. During this handshake, the client and
server agree on various parameters
used to establish the connection's security.



The handshake begins when a client connects to a TLS
-
enabled server
requesting a secure connection, and presents a list of
ciphers

and
hash
functions
.



From this list, the server picks the strongest cipher and hash function that it
also supports and noti
fies the client of the decision.



The server sends back its identification in the form of a
digital certificate
. The
certificate will usually contain the server name,

the trusted
certificate authority

(CA), and the server's public encryption key.

The client may contact the server of the trusted CA and confirm that the certifi
cate is
authentic before proceeding.



In order to generate the session keys used for the secure connection, the client
encrypts a random number with the server's public key, and sends the result to
the server. Only the server can decrypt it (with its privat
e key): this is the one
fact that makes the keys hidden from third parties, since only the server and
the client have access to this data.



Both parties generate key material for encryption and decryption.

This concludes the handshake and begins the secur
ed connection, which is encrypted
and decrypted with the key material until the connection closes.

If any one of the above steps fails, the TLS handshake fails, and the connection is not
created.

5.1.2.2

Content server certificate

Each service
provider

most have a
n
authorized certificate from a "certificate
authority" a temporary one can be generate by V
erisign

at
http://www.verisign.com/support/ssl
-
certificates
-
support/index.html


5.1.2.3

Content client certificate

The IIS also supports client certificates, using client certificates extends the security
of the transactions by enforcing that only client that posses the client certificates will
have access to the server. Using and configurin
g client certificates is out of the scope
of this document.


5.1.3


Authentication

ASP.NET authentication modes include Windows, Forms, Passport and None
:



Windows authentication
. With this authentication mode, ASP.NET relies
on IIS to authenticate users and crea
te a Windows access token to represent
the authenticated identity. IIS provides the following authentication
mechanisms:



Basic authentication.



Digest authentication



Integrated Windows authentication.



Certificate authentication.



Anonymous authentication




Passport authentication
. With this authentication mode, ASP.NET uses the
centralized authentication services of Microsoft Passport. ASP.NET provides
a convenient wrapper around functionality exposed by the Microsoft Passport
Software Development Kit (SDK
), which must be installed on the Web
server.



Forms authentication
. This approach uses client
-
side redirection to forward
unauthenticated users to a specified HTML form that allows them to enter
their credentials (user name and password). These credential
s are then
validated and an authentication ticket is generated and returned to the client.
The authentication ticket maintains the user identity and optionally a list of
roles that the user is a member of for the duration of the user's session.



None
. None

indicates that you either don't want to authenticate users or that
you are using a custom authentication protocol.


The solution uses

Forms authentication

as

authentication mode for to following
reasons:



Using windows or password authentication force us

to provision the user to
the AD or to Microsoft Password accordingly. We want the user to use the
provided service for its provisioning.



The authentication itself is done against the user's records in the
Content
Server



The authentication uses basic authe
ntication (
compeering

user name and
password

against the DB)



Because we are using TLS and all the data sent to the server is encrypted
working with basic authentication is allowed.



User's Password is not stored explicitly on the DB. Instead a MD5 hash of
the
password is stored there.



Even if someone

breaks into the DB, he
will not be able to use the
stolen
passwords
because
the FE
sends

to the content
-
server the hashed password.



If the user is not active for 5 min his session will be expires and he will
re
direct to the login page.


5.1.4

Authorization

The user is only
authorized to use the main page for manipulating his files only after
its authentication.


In each transaction triggered by the user the web site gets the encrypted user id from
his session cookie a
nd decrypt it
-

this way we can rest sure that the user real
credential are used.


5.2

Application server

5.2.1

Gate keeper


The
Application S
erver

is a Server and a client in its nature so its
Gate

keeper need to
be configure for incoming connections only from t
he
p
roxies

and outgoing to the
Mailing Server
. The only open ports are the ones of the
Remotting
.


The Gate configuration:


In

Out

IP

Proxies

list

Mail Server IP

Port

TCP
8987

8987



5.2.2

Secure Communications

The solution uses the .net Remoting security as
defined above.

5.2.3

Authentication

In this stage we authenticate the service that reform the action. The client
authentication is done in his login fase.


Each Remote method that the
Application Server

expose receives a
ServiceCredentialsIfc

argument. In it the

service put his service
-
id and password.


The
Application server

authenticates the service by Basic Authentication against Data
Base records.


5.2.4

Authorization



Service authorization

Once the service is authenticate its authorized to freeform actions on the
remote interface



User authorization

The user is only authorized to perform actions on his files. Authorization to
get others files is checked against invitations from others.




5.3

Data Base server

5.3.1

Gate keeper


The data base Server security is based on build

in MS securety


The Gate configuration:


In

Out

IP

Application server

none

Port

TCP
1433

none



5.3.2

Secure Communications

No need because it's in internal network

5.3.3

Authentication

A
n DB user will be added. The user will be the user that is running the
appl
ication
server
,


so the authentication is done by LDAP.

5.3.4

Authorization

This user will only be authorized to perform logic actions on the schema.


6

U.Cs D
iagrams

6.1

Client connection negotiation



Taken from
http://conferences.codegear.com/article/images/32136/1348c.jpg



6.2

Client
accessing web server



6.3

New Client Registration



6.4

Files managing

6.4.1

Uploading files


6.4.2

Deleting a file


6.4.3

Downloading a file


6.4.4

Send file

download invitation



6.4.5

Download a file from a friend