Web Hacking: Attacks and Defense

zenomorph writes: "I first heard of this book on amazon.com on a Monday morning, and read the reviews of people who had purchased this book. I noticed that there were no reviews from any person in the web security community had commented on it, either on Amazon or anywhere else (with the exception of two brief comments on the back of the book, of which one was written by the person who wrote the book's foreword). So I decided to pick it up on Friday after I left work and see what it had to offer. After picking up the book I noticed it was co-authored by three people who all work for Foundstone, a very large security company that deals with everything (including web security). This review will cover some of the topics covered in this book, along with things that could or should have been covered in greater detail." Read on for the rest of zenomorph's review. Web Hacking: Attacks and defense author Stuart McClure, Saumil Shah, and Shreeraj Sha pages 492 publisher Addison-Wesley rating 8 reviewer zenomorph ISBN 0201761769 summary Web Application Hacking

Target audience: This book is geared more towards beginners and intermediate users, with a few things the more advanced people will enjoy. It explains concepts and practical examples in an easy to understand manner. Pros:

One portion of the book covered a topic which is rarely mentioned and almost never documented in security texts, which is ASP (Active Server Pages). This primarily covered security involving databases handling and login information. Another rarely documented subject this book covered was ISAPI application security. Additional good points below:

• Good examples of the types of commands an attacker will execute when remote command execution is possible. Also had a nice little attack fingerprint reference in the back. (Appendix D Page 462)

• General Tips and tricks for fingerprinting a web server, and database versions. (pages 182-194) Provides this information based on error messages and URL structure.

• Chapter 12 covers remote command execution threats with Java and Java servers. Definably a book highlight. Not too much documentation currently exists on this ever-growing web technology.

• Chapter 14 covers buffer overflows in a very easy to understand manner; something not easily accomplished for the less tech-savvy. It also walks through a complete example of bad code, to writing and executing the exploit.
• One nice section is the "Cheat Sheet" towards the back of the book which provides the most common improperly used functions in ASP, PHP, Java, and Perl. I did notice it left out the ever popular fopen() function in PHP, which is very popular for attackers to exploit when improperly used (Code inclusion attacks).

• Shows good practical examples of attackers using search engines to help further probe a site.

• Covers SQL and Oracle security. (Direct, and Injection based attacks)

• Web Application server security was covered with examples on BEA Weblogic, and Websphere.

• Provides good examples of using tools such as Netcat, Sam Spade, Teleport Pro, Black Widow, Webcracker, Brutus, Achilles, Cookie Pal, etc.

• Coveres the threats of Internet worms,including the effect on the Internet of Nimda, and Code Red. Gave details of what exactly they did, and how they could spread.

• Chapter 17 is a treat. Covers how attackers avoid IDS systems through the use of SSL, and URL encoding (such as Unicode, 2-byte, 3-Byte, and double encoding.) Also covers how to set up an IDS on SSL via reverse proxies.

Cons: This book was released in August of 2002, but I couldn't find any reference to cross-site scripting. Cross-site scripting isn't a new type of attack. In fact, it has been around since the late 1990's. More gripes below:

• The authors have a tendency to include snippets from IRC conversations. While it's explaining how hackers communicate during attacks I found it a little lame. I'd rather they had mentioned some "hacker" channels, or something along those lines.

• Neither cookie theft nor poisoning is mentioned, while cookie modification is.

• I went to the back of the book hoping to gather some good references for further reading and only got a small links section showing 6 links, none of which where technical documents but instead general web links.

• Web application abuse and spamming aren't covered at all, which is something very important and an ever-growing option for spammers.

• No references to XML-RPC or SOAP were found but the athors do briefly mention Microsoft's .NET technology without providing any code examples.

• Lack of web application wrappers and security. CGIWrap and Suexec aren't mentioned anywhere. Nothing about chrooting webservers, or applications for additional security were found.

• Apache's "Tomcat" server isn't mentioned anywhere, with the exception of an exploit mentioned in Appendix D. (Source Code, File, and Directory Disclosure Cheat sheet)

• Not a big complaint but it would have been nice if Python or TCL were covered.

Closing:

On a scale of one to ten I give this book an eight. This review was written to give you an idea of the contents, or lack thereof. Perhaps this will help you to decide if this book is what you're looking for, or a waste of time.

You can purchase Web Hacking: Attacks and Defense from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Comments

The book is a sham! Ignores secure-OS webservers!

[Anonymous Coward]

A book rating of 8!!! Ha!

I find it both sad and amusing that people try to publish books about this topic without first addressing the fact that there are more secure platforms for webserving. Most of these short-sighted me-too security bandwagon books concentrate onthe porous unix/linux offerings, or MS weaknesses, and avoid discussing Mac.

It is a concrete fact that that no MacOS based webserver has ever been hacked into in the history of the internet.

The MacOS running WebStar and other webservers as has never been exploited or defaced, and are are unbreakable based on ample historical evidence.

In fact in the entire SecurityFocus (BugTraq) database history there has never been a Mac exploited over the internet remotely. Scan it yourself.

That is why the US Army gave up on MS IIS and got a Mac for a web server.

I am not talking about FreeBSD derived MacOS X (which already had a more than a 30 exploits and potential exploits in BugTraq) I am talking about current Mac OS 9.x and earlier which are highly sophisticated abstract-OS models.

Why is is hack proof? These reasons :

1> No command shell. No shell means no way to hook or intercept the flow of control with many various shell oriented tricks found in Unix or NT. Apple uses an object model for procces to process communication that is heavily typed and "pipe-less"

2> No Root user. All mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stufff where you pass Gary Davidians birthday into certain registers and make a special call). By always being root there is no false sense of security, and programming is done carefully.

3> Pascal strings. ANSI C Strings are the number one way people exploit Linux and Wintel boxes. The mac avoids C strings historically in most of all of its OS. In fact even its roms originally used Pascal strings. As you know pascal strings are faster than C (because they have the length delimiter in the front and do not have to endlessly hunt for NULL), but the side effect is less buffer exploits. Individual 3rd party products may use C stings and bind to ANSI libraries, but many do not. In case you are not aware of what a "pascal string" is, it usually has no null byte terminator.

4> Macs running Webstar have ability to only run CGI placed in correct directory location and correctly file "typed" (not mere file name extension). File types on Macs are not easily settable by users, expecially remotely. Apache as you know has had many problems in earlier years preventing wayward execution.

5> Macs never run code ever merely based on how a file is named. ".exe" suffixes mean nothing! For example the file type is 4 characters of user-invisible attributes, along with many other invisible attributes, but these 4 bytes cannot be set by most tool oriented utilities that work with data files. For example file copy utilities preserve launchable file-types, but JPEG MPEG HTML TXT etc oriented tools are physically incapable by designof creating an executable file. The file type is not set to executable for hte hackers needs. In fact its even more secure than that. A mac cannot run a program unless it has TWO files. The second file is an invisible file associated with the data fork file and is called a resource fork. EVERY mac program has a resource fork file containing launch information. It needs to be present. Typically JPEG, HTML, MPEG, TXT, ZIP, C, etc are merely data files and lack resource fork files, and even if the y had them they would lack launch information. but the best part is that mac web programs and server tools do not create files with resource forks usually. TOTAL security.

4> Stack return address positioned in safer location than some intel OSes. Buffer exploits take advantage of loser programmers lack of string length checking and clobber the return address to run thier exploit code instead. The Mac compilers usually place return address in front or out of context of where the buffer would overrun. Much safer.

7> There are less macs, though there are huge cash prizes for cracking into a MacOS based WebStar server (typically over $10,000 US). Less macs means less hacker interest, but there are MILLIONS of macs sold, and some of the most skilled programmers are well versed in systems level mac engineering and know of the cash prizes, so its a moot point, but perhaps macs are never kracked because there appear to be less of them. (many macs pretend they are unix and give false headers to requests to keep up the illusion, ftp http, finger, etc). But some huge high performance sites use load-balancing webstar. Regardless, no mac has ever been rooted in history of the internet, except with a strange 3rd party tool in 1995.

8> MacOS source not available traditionally, except within apple, similar to Microsoft source only available to its summer interns and engineers, source is rare to MacOS. This makes it hard to look for programming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.

Sure a fool can install freeware and shareware server tools and unsecure 3rd party addon tools for e-commerce, but a mac (MacOS 9) running WebStar is the most secure web server possible and webstar offers many services as is.

One 3rd party tool created the only known exploit backdoor in mac history and that was back in 1995 and is not, nor was, a widely used tool. I do not even know its name. From 1995 to 2002 not one macintosh web server on the internet has been broken into or defaced EVER. Other than that event ages ago in 1995, no mac web server has ever been rooted,defaced,owned,scanned,exploited, etc.

I think its quite amusing that there are over 200 or 300 known vulnerabilities in RedHat over the years and not one MacOS 9.x or older remote exploit hack. There are even vulnerabilities a month ago in OpenBSD! Each month vulnerabilities in XP arise.

Not one exploit. And that includes Webstar and other web servers on the Mac.

A rare set of documentation tutorials and exercises on rewriting all buffer LINUX exploits from INTEL to PowerPC was published less than a year ago. The priceless hacker tutorials were by a linux fanatic : Christopher A Shepherd, 3036 Foxhill Circle #102, Apopka, FL 32703 and he wrote the tutorials in a context against BSD-Mach Mac OSX. but all of his unix methods will find little to exploit on a traditional MacOS server.

BTW this is NOT an add for webstar.. the recent versions of webstar sold for over the last year are insecure and cannot run on Mac OS 9.x or 8.x, and only run on the repeatedly exploited MacOS X.

--- too bad the linux community is so stubborn that they refuse to understand that the Mac has always been the most secure OS for servers.

BugTraq concurs! As does the WWW consortium. So you do not need a book to teach you how to pathetically try to secure a website, just use a Mac, as many colleges and large media sites do, and many commercial airlines for their in-house security.