1 / 16

Web Applications

Web Applications. Web-Based Applications. General Issues.

ginata
Download Presentation

Web Applications

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Applications Web-Based Applications

  2. General Issues Web attacks are much less frequently directed at applications on a server than the server itself. Unless the application is commonly installed (A web server version, default CGI applications, or common misconfigurations (PERL)), the attacker would need to spend extra time trying to understand the application being attacked. At this point, the preference is usually to try common attacks against that server.

  3. CGI Programming • CGI is the Common Gateway Interface between an external application and the web server. When an application is called from a designated CGI directory, such as /cgi-bin/, the server will execute the program and return STDOUT to the web browser. • The CGI application receives POST’ed information via STDIN, and other information through environment variables. (HTTP_USER, REMOTE_HOST, REMOTE_ADDR, etc.)

  4. CGI Programming (cont..) • As the CGI application is executed as a process external to the web server, there are several issues: • Security, as the program is external to the web server, it is not limited in its actions. Users with CGI access have full access to server resources. • Speed, the program must be started up, executed, and terminated before the user can complete their request. For scripting languages such as Perl, the Perl interpreter must be started up, interpret the script, and execute before the client receives its information. • Flexibility, since the server simply receives the STDOUT from the application, there is no real interaction between application and web server.

  5. Example CGI Script #!/bin/perl print “Content-type: text/html\n\n”; print “<PRE>\n”; foreach $n (keys %ENV) { print “$n $ENV{$n}\n”; } print “</PRE>\n”;

  6. Common Problems • Shell Escapes • Programs often times will need to call an external program to perform some sort of operation that would be difficult to program, such as a search or complex processing function. If the user arguments are not heavily filtered, users may be able to execute arbitrary commands on the server. • Authentication Passing • Scripts have a difficult time passing authentication between screens, given the disconnected nature of the web. (Re: HTTP) Many times authentication information will be passed in form arguments or URL strings, which opens it to disclosure or tampering.

  7. Common Problems (cont.) • Temporary Files • This problem is limited to servers where users may have access to the environment. Occasionally a server application needs to process data into temporary files, such as when an external program needs to be accessed. If a user has access to the server, they could read the data in these files, and potentially replace the information being returned to the user. (Race Condition)

  8. Example Problems - shell escapes #!/bin/perl print “Content-type: text/html\n\n”; $username = $ENV{‘QUERY_STRING’}; open(RESULTS,”w $username |”); $results = <RESULTS>; close(RESULTS); print “User Information: $results\n\n”;

  9. Example Problems - authentication <FORM ACTION=“/cgi-bin/whoop.pl” METHOD=POST> <INPUT NAME=“favcolor” LENGTH=50> <INPUT TYPE=HIDDEN NAME=“username” VALUE=“myuser”> <INPUT TYPE=HIDDEN NAME=“password” VALUE=“verysecret”> <INPUT TYPE=SUBMIT VALUE=“Go For It!”> </FORM>

  10. Example Problems - authentication url http://www.mysite.com/cgi-bin/myapplication.pl?value1=123&value2=812&format=fmt1&bleh=blehbleh&stuff=morestuff&username=myuser&other=info&etc=etc This is an example of two problems. The first is passing authentication information in plaintext within the URL. The second problem is that the username alone is passed, leaving intruders free to simply replace the username with one of their choosing. (Ie: username & password check is performed at one location only.)

  11. Beyond CGI • Other server programming environments include: • NSAPI/ISAPI/ASAPI • Programming C code directly into the web server. Much less frequently used, therefore less general problems with it. Buffer overflows, etc possible. • Livewire/Server-Side JavaScript • Under the Netscape Enterprise server, JavaScript code can be compiled into a page to be executed at page load time. No new issues arise in this, except that system calls aren’t used so are not a problem. Livewire has its own problems with reliability anyway.

  12. Beyond CGI (cont.) • ASP/Server-Side VBScript • Within IIS, VBScript can be embedded within pages to be resolved at page load time. This is similar to Livewire in its pro’s and con’s, except that it has the overhead of NT to deal with. • An example problem that recently occurred was the ability to fetch /myfile.asp::$DATA, to retrieve actual file contents from the server. (ASP files frequently contain database name/passwords, etc..) • Java Servlets • Usually no external programs executed, generally fast and scalable. Java enforced error checking helps keep apps safer.

  13. Recent Issues • PHF Scans • Many web servers that installed default NCSA or Apache CGIs (from a few years ago) have a script called phf, with an easy to exploit shell escape. Attacks are common against this CGI, and are still somewhat successful. There are still reports of sites being compromised via this application, and unless a server is specially monitored, this attack would go unnoticed. • How to check for attacks: grep cgi-bin/phf logs/errors • Real-time notification: Put in a phf script that mails the server admin on probes to this script. Several exist out there to do this.

  14. Recent Issues • Yahoo • The web server serving text versions of the yahoo site was compromised and text replaced. The attack and modification was noticed in minutes, and the content was fixed. • The server appeared to have been compromised through buffer overflows in the web server itself. The system was running under PC-based UNIX, making attack scripts common and easily retrieved. This was solved by upgrading to the current release of the web server. • Points: The content was being monitored for any unscheduled changes, and replaced with the current version. The server should have been kept up to date, but most are not.

  15. Sites • Site: www.cnn.com • Server: Netscape-Enterprise/2.01 • Site: www.microsoft.com • Server: Microsoft-IIS/4.0 • Site: www.netscape.com • Server: Netscape-Enterprise/2.01 • Site: www.apple.com • Server: Netscape-Enterprise/3.5.1C • Site: www.cnet.com • Server: Netscape-Communications/1.12 • Site: www.oracle.com • Server: Oracle_Web_listener3.0.1.0.0/2.14FC1 • Site: www.sgi.com • Server: Netscape-Enterprise/3.5.1G • Site: www.excite.com • Server: Netscape-Enterprise/2.01

  16. Recent Issues • NY Times • The New York Times web site was compromised and vandalized with junk and pornographic images. Details are limited about the specifics of the attack, but in general (gossip, atleast..): • The web site appears to have had weak server security. Beyond the web servers, applications and configurations on the site were weak. • Limited monitoring of the server environment. • Solutions? Monitoring pages for changes, strict/minimal server configurations.

More Related