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.
"So I decided to pick it up on Friday after I left work and see what it had to offer...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"
Ok, so its a 492 page technical resource, and you just *bought* the book 5 days ago?
Is it possible that maybe you missed some things?
I mean, I can read a good 500 page novel in a day or two, but I don't think I'd give a review on a technical book I just bought 5 days ago. Maybe that's just me.
Scanning a network doesn't make it secure, but we've all run into people
who think it does-- including people who should know better.
I agree that scanning a network doesn't make it secure but rather it is the first step in identifying where it is insecure. It's an important step that should not be overlooked. As far as the book goes, anything to help people realize that security is important is a good thing.
The problem I have with these reviews and those that are found on Amazon, is that there is no context for the review. Specifically, what's great to you might suck to me. We have no knowledge of the reviewers skill level or experience.
It would be far better if the reviewers would give a little background information about themselves, along with the review.
What is Zenomorph's skill level? How long have they worked in this field? What related hardware and software are they proficient with? What other books on the subject has this person read and what was their opinion of those books? Without this information the review carries no more weight than one from Jon Katz.
It's a simple fact that 95% of "attacks" are quite harmless game-playing by "script kiddies", against which there's no need to defend.
Last I checked having some HTML file written in FrontPage saying "j00 h4v3 b33n 0wnz0r3d" in red on black where your index page is supposed to be doesn't do wonders for your company's reputation.
The problem I have with these reviews and those that are found on Amazon, is that there is no context for the review. Specifically, what's great to you might suck to me. We have no knowledge of the reviewers skill level or experience.
It would be far better if the reviewers would give a little background information about themselves, along with the review.
What is Zenomorph's skill level? How long have they worked in this field? What related hardware and software are they proficient with? What other books on the subject has this person read and what was their opinion of those books? Without this information the review carries no more weight than one from Jon Katz.
I have spoken.
Hiding the information from the general public doesn't do any good either. You know how everyone keeps bashing MS for not disclosing holes, it's the same thing with not wanting to publish info on how to hack a system. A capable system administrator will take this info and secure their boxes against the holes published in these books. They are just too busy to be looking for such obscure information as finding holes in software. These books provide valuable insight from people who are working in the field and as a security administrator for a rather large company, I place high value in these books.
I find it quite interesting that you assume that any people of note should bother submitting a review to Amazon.com if they have something to say about a book. If I were going to take the time to write a professional review of a book, I'm sure that I would have it published somewhere that I would get good exposure and receive compensation for my time.
Maybe you would like to take a look at Web Security, Privacy & Commerce, 2nd Edition from OReilly (I have no connection w/ this link or this book).
Or maybe you could figure out where the Web Security zealots hang out. I bet they've talked about the book there, if it has any merit of note.
If you expect anything besides rehashes of the books TOC on the Amazon.com review system, you're going to be disappointed most of the time.
-S
We Apprentice Developers and Designers
no shit. it's like walking around your building and noting where the weak points are. thinking you know something (such as what is/isnt running on your network) is different than actually looking. i might think there is only one door into the server room snce thats what the architects told me, but unless i go and look, how do i know for sure?
now if i gather that information and dont use it, i'm a DUMBASS. but i use the info i gather, so im not a dumbass (well, for that reason at least).
while scanning by itself doesn't make a network more secure, not scanning is foolish.
Well, actually, it isn't a first step. The first step is reviewing policies. If no policies are in place, knowing what is secure or insecure is almost irrelevent. Once you've analyzed the policies, go over what is missing, clarify what is unclear, ensure that what is required is sensible, and work through everything to make sure the policy is clear and enforced.
Now, once you know what is and isn't allowed, you might want to scan and see what's there. Remember, just because something is a potential vulnerability doesn't mean it has to be changed. A cost/risks analysis may have been done with the determination that a given "hole" has sufficient reward to justify the risk. But until you've gone over the policies and reviewed the business reasons for any given service, you can't determine if it is a hole or not.
RagManX