Slashdot Mirror
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.
He is the administrator of cgisecurity.com, a web security news site. He's written a few papers and advisories. Check out the site.
"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."
Ummm... here is a free version of that information. Very thorough, and it is by RFP the writer of whisker.
(Score:0) ???
Geeze, some people just don't recognize sarcasm when they see it.
The point here is, in many instances the PATRIOT act is written so broadly that it may be construed that the mere mention of anything security related is deemed an unpatriotic, seditionist, revolutionary plot.
My office has been taken over by iPod people.
I took the Foundstone "Ultimate Hacking" course a few months ago, and some of these guys were on the team who taught it. While I can't speak to the book itself, not having read it, the authors themselves were very knowledgeable and authoritative in their fields. I expect that the information in this book should (hopefully) be of the same caliber.
"You can never have too many elephants on your team."
Considering that the book is written by the team at Foundstone, guys who have written other books on security such as Hacking Exposed, Hacking Linux Exposed, and Hacking Windows 2000 Exposed, teach courses in network security, such as Ultimate Hacking and Ultimate IDS, and have been doing this for countless years, Id have to say itd probally be a pretty good book on the subject. While not all topics are covered, as the reviewer pointed out the book is geared towards novices to intermediate users.. so dont expect everything. Not knowing the reviewers skill level, Ill trust that the Foundstone guys wrote a fairly decent book and expect that a few things are either held back due to relevence or space. And chances are I will probally pick it up myself in one of my future book runs. If someone who reads the book is all that interested in the security field after reading it, it will at least give them a starting point to start looking and discover some of the missing elements mentioned in the review...
Another book by the Foundstone crew is Hacking Web Applications Exposed. I found this book to a lot better than Web Hacking: Attacks and Defense. I know a bunch of the guys over at Foundstone and personally, I find Shema's book to be a lot better than Shah's.
Just a little insight.
Parent is a copy-and-paste karma whore.
Every categorical statement about computer security is wrong.
If you talk to anyone in the top rank of information security, whether someone with a public profile like Bruce Schneier or Ross Anderderson or people like Jeff Schiller, Butler Lampson, Steve Bellovin or myself who are well known in the industry but may not pop up in print as often you will get a fairly consistent reply on the value of various strategies but in every case you will be told that what is meant 'secure' depends on your particular needs.
What you will not get is computer security boiled down to a simple set of rules. You might get 'Security is risk control, not risk elimination' which has been arround for several decades before Bruce recently claimed it.
What security is not is the set of ideological slogans that tend to infest slashdot. For example 'security through obscurity' is regularly brought out to attack what are actually valid security strategies. It took several years to get the unix community to undersand that shadow passwords are not a form of security through obscurity. Many folk on slashdot think that unix has always had them.
Before looking at site policy or anything else suggested so far as the 'first step' ask yourself what assets do I have and what damage would be caused if they were disclosed, erased or otherwise damaged?. This is actually quite a hard question and many people will miss out their most important assets. For example the CIA and NSA failled to consider their reputation as an asset when they outsourced the running of their Web sites with embarassing results when they were hacked. The Whitehouse did not make that mistake. Before the site ever went online they realised that the Web site was potentially a reputation asset. The first target of a coup is always the television station since the coup plotters can often get people to comply with the revolution just by announcing that it has taken place. Also they had been bitten during the 1992 election campaign when an NRA supporter sent out a fake press release promissing an imminent gun grabbing. Ironically the response to the fake release suggested that gun grabbing was popular, so know you know who you have to blame.
As for the book, it sounds to me that this is a very 'down in the trenches' type of book. I don't worry about a lot of the attacks described because I would never go near certain technologies. Client side Java, Javascript and other 'winky-blinky' technology would have been much better if never invented. However when you come to build systems you can still have problems because even though you may not use javascript a weakness in javascript could compromise a mechanism you relly on such as session cookies.
I just gor Ross Anderson's book 'Security Engineering'. I have not read it yet but his monograph 'why security protocols fail' is the one that Bruce, Ron Rivest or myself all refer to if we want to quickly install some clues into someone designing a protocol with inadequate security...
Looking for an Information Security student project suggestion?
Try http://dotcrimeManifesto.com/
Dammit, troll instead of funny? C'mon, have a heart -- the guy was funny.
...other than that event ages ago in 1995, no mac web server has ever been...scanned...
Oh, well. Here we go.
It's a concrete fact that no MacOS based webserver has ever been hacked into in the history of the internet.
Heh
The MacOS running WebStar and other webservers as hs never been exploited or defaced, and are unbreakable based on ample historical evidence
It's easy to write a secure webserver. It's a little harder to write one that does useful work *and* is secure. I can write a secure webserver in an afternoon. Start adding on forums or something worthwhile to a WebStar server and you'll see security holes.
That is why the US Army gave up on MS IIS and got a Mac for a web server
The Army dropped IIS because it's a bug-laden insecure piece of shit that's been responsible for more break-ins than any other piece of software in the history of mankind. That doesn't mean that Mac OS based webservers are ideal, mate.
I am not talking about FreeBSD derived MacOS X (which already had more than 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.
Ah, yes. Classic Mac OS. No memory protection, if my memory of 7.x days serves me well. An exploit of the server is an exploit of the whole machine. No chroot.
Why is it hack proof?
Hehe
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 process to process communication that is heavily typed and "pipe-less"
You're talking about command line arguments? Doesn't have anything to do with piped communication.
No root user. All mac developers know their code is always running at root. Nothing is higher (except undocumented microkernel stuff 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.
Yeah, I did development on System 7.x for a while. It does teach you to be damn careful with those pointers -- crash "Damn, gotta reboot so I can change one line, recompile, and try again!". I don't buy it.
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 sings 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
Pascal strings are a fucking archaic scheme dating from times when you statically allocated 255 byte strings and then had a size byte to tell you how much you were actually using. They cap you at 255 bytes. You can do bounds-checked arrays in C, just as you can in Pascal. Not everyone does so, but the same applies to the Mac and Pascal strings, as you pointed out. Furthermore, using UNIX or Windows doesn't mean that you have to use C/C++. In the GNU Compiler Collection alone, you have Java, fortran 77, objective C (*cough* like MacOS X), and Ada support, all of which have bounds-checked strings.
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, especially remotely. Apache as you know has had many problems in earlier years preventing wayward execution.
Yeah? And UNIX has an executable bit. If someone can get it and flip permission bits and rename files, the chances are pretty good that they can change file types.
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 design of creating an executable file. The file type is not set to executable for the hacker's 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 they 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.
This is why every communication program for the Mac supports MacBinary. If you can upload something to the system, you can pretty assuredly toss a resource fork up.
Stack return addresses positioned in safer location than some intel OSes. Buffer exploits take advantage of loser programers lack of string length checking and clobber the return address to run their exploit code instead. The Mac compilers usually place return address in front or out of context of where the buffer would overrun. Much safer.
Take a look at the first link on this Google search. Secure or not?
There are less macs, though there are huge cash prizes for cracking into a MacOS based WebStar server (typically over $10,000 US)
This happened *once*, laddie buck.
Less macs mean 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.
Some of the most skilled programmers are systems level Mac coders? I mean, it's not *impossible*, but is there a Archangeli or a Cox in the MacOS world? If there is, they likely work for Apple and aren't out trying to break into web servers.
But some huge high performance sites use load-balancing webstar.
Why should you *not* use a classic Mac for a high-powered server?
Let's see. If we have more than one process doing anything on the system, we run into the complete lack of preemptive multitasking. If an administrator is doing something at the console, everything except for interrupt-driven crap stops cold. Bit of an issue. There's the lousy VM in the classic Mac OS. HFS/HFS+ is not the most impressively high performance filesystem ever. Caching in the classic Mac OS sucks.
Classic Mac OS was designed to be a workstation. Servers were not in the mind of the designers at all. That doesn't matter -- it makes a fine workstation for many people. But pimping it as a server is silly.
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 fo rprogramming mistakes, but I feel the restricted source access is not the main reasons the MacOS has never been remotely broken into and exploited.
So by your logic, there should be no IIS exploits.
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
People who install Apache are fools?
I really hate to break this to you, but you're in error here.
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.
Those 200 to 300 vulnerabilities you list are *local* exploits, you idiot. Classic Mac OS doesn't list those because by using the computer you are engaging in one giant exploit...able to read other users files and whatnot. If Apple was as ambitious as Red Hat is, they'd be listing "local vulnerabilities" as well. Apple doesn't go out of their way to point out holes that they *do* have. Furthermore, Red Hat ships with *servers* to exploit. The Mac OS doesn't *do* anything out of box as regards serving, so there isn't much to exploit. If you don't care about doing anything, an off computer is even more secure.
BTW, I distinctly remember Apple never shipping a free update to Open Transport to fix some vulnerabilities in the TCP implementation for those of us with System 7.5.x. That *is* attackable.
May we never see th
Don't click on slashdots link to buy the book from Barnes and Noble. It is listed there at $39.99. Amazon [amazon.com] has the same book [amazon.com] for $34.99.
1 76 9
Save yourself some money.
Dude! DONT buy from amazon!!! it's only $28.95 at bookpool.com the ultimate online tech bookstore!
http://www.bookpool.com/.x/d4aysbtukr/sm/020176