I NTRODUCTION TO W EB S ECURITY by Fabrizio dAmore Department of - PowerPoint PPT Presentation

I NTRODUCTION TO W EB S ECURITY by Fabrizio d’Amore Department of Computer, Control, and Management Engineering Antonio Ruberti Sapienza University of Rome

WHY W EB S ECURITY April 2013 ¢ recent studies conform a trend that has been observed in last 8 years: strong increase in (quality and number of) threats related to client-server / intro web security multi-tier applications, adopted in Web 2.0 applications ¢ complex scenario, because preventions requires study of software components and of their interactions ¢ critical components are always Web server and browser — other possible critical components: DBMS server and application server 2

A FEW FUNDAMENTAL PRINCIPLES April 2013 source: Open Web Application Security Project (OWASP) https://www.owasp.org/index.php/Main_Page Principles (https://www.owasp.org/index.php/Category:Principle) intro web security ¢ Apply defense in depth layered (horizontal) and/or structured (vertical) security mechanisms increase — security don't rely on a unique defense (e.g., a firewall) — ¢ Use a positive security model based on white lists , it prevents by definition new types of attack — ¢ Fail securely (handling errors securely is a key aspect of secure coding) type 1 errors exceptions that occur — in the processing of a security control, they should disallow the operation type 2 errors exceptions in code that — is not part of a security control: they could affect the way a security 3 control is carried out

MORE OWASP PRINCIPLES April 2013 ¢ Run with least privilege accounts should have the least amount of privilege required to perform their business — processes ex.: don't connect to mysql DB as root, you don't need that (normally) — ¢ Avoid security by obscurity intro web security it is a weak security control, and nearly always fails when it is the only control — instead, use security controls based on open and know principles — vulnerabilities come from lack of open principles, not from secrecy — ¢ Keep security simple verifiable, economy of mechanism — minimize attack surface (the larger, the more complex) — ¢ Detect intrusions (compromise recording) log security-relevant events — ensure logs are monitored regularly — properly respond to an intrusion once detected — ¢ Don’t trust infrastructure do you know its details? — what do you know of its design principles? — ¢ Don’t trust services they could refer to external resources — ¢ Establish secure defaults (psychological acceptability) 4 example: password aging enabled by default but users can disable it —

THE RISKS ( WEB SECURITY ) April 2013 l server side risks - mainly related to system & application configuration intro web security l client side risks - browser related l risks coming from network - at any point of the path client-server 5

RISKS AT SERVER SIDE April 2013 l data stealing l commands execution intro web security l collecting data for intrusion setup l DOS (denial of service) attacks - several typologies 6

RISKS AT CLIENT SIDE April 2013 l mainly related to browser l active contents might cause browser’s crash, damage intro web security user system, violate privacy… l attackers can also execute arbitrary code (botnets) l use & abuse of private information, obtained from user l user can be aware or unaware l identity thefts 7

RISKS COMING FROM NETWORK April 2013 l eavesdropping l i.e., capture of transmitted data between browser & server by means of electronic interception intro web security l interceptors can operate everywhere in the path between browser & server - network at browser’s side - network at server’s side (includes intranet) l user or server ISP l ISP’s access provider 8

SECURITY AT SERVER SIDE April 2013 l related to applications offering services l Web server plays crucial role intro web security l we'll see a few important points - correct setting of file access permissions - optional services - userid of server process - shared ftp/www areas - server in chroot environment - www server & firewall - recognize compromised servers 9

IMPORTANT DIRECTORIES April 2013 ¢ document root — folder in Web server designated to contain Web pages intro web security — synonymous: start directory , home directory , web publishing directory , remote root etc. — typical names of document root: htdocs htdocs , httpdocs httpdocs , html , public_html public_html , web, www web, www etc. html ¢ server root — contains logs & configurations — a few scripts put here their working directory 10

FILE PERMISSIONS April 2013 l be aware of permissions given to directories - document root, containing HTML documents - server root, containing log & configuration files; often CGI intro web security scripts run here - the Common Gateway Interface (CGI) is a standard (RFC3875) that defines how Web server software can delegate the generation of Web pages to a console application. Such applications are known as CGI scripts; they can be written in any programming language, although scripting languages are often used l good idea: purposely define username and group l e.g., www & wwwgroup - home directory of www is server root - HTML authors should be added to wwwgroup 11

PERMISSIONS OF SERVER ROOT April 2013 l only www should have rwx access everywhere l wwwgroup could have rx access everywhere and w on intro web security contents l others should have rx access on contents and cgi-bin drwxr-xr drwxr xr-x 5 www -x 5 www wwwgroup wwwgroup 1024 Aug 8 00:01 1024 Aug 8 00:01 cgi cgi-bin/ -bin/ drwxr-x--- 2 www drwxr -x--- 2 www wwwgroup wwwgroup 1024 Jun 11 17:21 1024 Jun 11 17:21 conf conf/ / -rwx rwx------ 1 www ------ 1 www wwwgroup wwwgroup 109674 May 8 23:58 109674 May 8 23:58 httpd httpd drwxrwxr-x 2 www drwxrwxr -x 2 www wwwgroup wwwgroup 1024 Aug 8 00:01 1024 Aug 8 00:01 htdocs htdocs/ / drwxrwxr drwxrwxr-x 2 www -x 2 www wwwgroup wwwgroup 1024 Jun 3 21:15 icons/ 1024 Jun 3 21:15 icons/ drwxr drwxr-x--- 2 www -x--- 2 www wwwgroup wwwgroup 1024 May 4 22:23 logs/ 1024 May 4 22:23 logs/ 12

PERMISSIONS OF DOCUMENT ROOT April 2013 l since the Web server should run as nobody document root should have permissions o+rx intro web security l in order to allow HTML authors to insert contents document root should have permissions ug+rwx l same permissions for subdirectories drwxrwxr drwxrwxr-x 3 www -x 3 www wwwgroup wwwgroup 1024 Jul 1 03:54 contents 1024 Jul 1 03:54 contents drwxrwxr drwxrwxr-x 10 www -x 10 www wwwgroup wwwgroup 1024 Aug 23 19:32 examples 1024 Aug 23 19:32 examples -rw rw-rw rw-r-- 1 www -r-- 1 www wwwgroup wwwgroup 1488 Jun 13 23:30 index.html 1488 Jun 13 23:30 index.html -rw rw-rw rw-r-- 1 -r-- 1 lstein lstein wwwgroup wwwgroup 39294 Jun 11 23:00 tmp.html 39294 Jun 11 23:00 tmp.html 13

PERMISSIONS OF DOCUMENT ROOT 2 April 2013 l many Web servers allow selective access to portions of document root, based on browser’s IP or authentication intro web security l however if document root has permissions o+rx local users will be allowed to access all of the contents l solution: server process runs with id different from nobody , with minimal privileges and belonging to wwwgroup l permissions g+rx and o-rwx for “restricted” sections l warning: if we use g+rwx also the Web server will be able to overwrite contents 14

PERMISSIONS OF DOCUMENT ROOT 3 April 2013 • if there exist specific reasons for making the Web server running with other userid, make sure that log directory is not writeable for such userid intro web security • otherwise an attacker could exploit a bug in some script and replace a log file with a symbolic link to / etc/passwd : when service is restarted a chown of / etc/passwd occurs and the attacker will be able to add a new line to that file • some workarounds exist 15

OPTIONAL SERVICES April 2013 ¢ most Web servers have additional capabilities, that can increase the risk intro web security — automatic directory listing — symbolic link following — server side include — user maintained directory 16

OPTIONAL SERVICES / DIRECTORY LISTING April 2013 ¢ knowledge is power — backup files left by text editors, maybe with scripts source code intro web security — temporary directories and files — symbolic links, that have been created for convenience, but that have never been removed — source code control logs ¢ disabling the directory listing does not prevent from guessing file names — all unnecessary files should be carefully removed 17

OPTIONAL SERVICES / SYMBOLIC LINK FOLLOWING April 2013 ¢ extending the document tree with symbolic links could be useful, but awkward actions could make reachable delicate directories, such as /etc intro web security — apache can be configured to allow following of symbolic links, but only when link owner and destination owner do coincide, so that possible damages are limited to such owner ¢ another approach allows to extend the document tree directly acting on the configuration (e.g., alias of apache ) 18