How They Hack Your Website: Overview of Common Techniques By JOHN CONROY | Mar 5, 2008
We hear the same terms bandied about whenever a popular site gets hacked. You know‌ SQL Injection, cross site scripting, that kind of thing. But what do these things mean? Is hacking really as inaccessible as many of us imagine; a nefarious, impossibly technical twilight world forever beyond our ken? Not really. When you consider that you can go to Google right now and enter a search string which will return you thousands of usernames and passwords to websites, you realize that this dark science is really no mystery at all. You'll react similarly when you see just how simple a concept SQL Injection is, and how it can be automated with simple tools. Read on, to learn the basics of how sites and web content management systems are most often hacked, and what you can do to reduce the risk of it happening to you.
SQL Injection SQL Injection involves entering SQL code into web forms, eg. login fields, or into the browser address field, to access and manipulate the database behind the site, system or application. When you enter text in the Username and Password fields of a login screen, the data you input is typically inserted into an SQL command. This command checks the data you've entered against the relevant table in the database. If your input matches table/row data, you're granted access (in the case of a login screen). If not, you're knocked back out. SPONSORSHIP CMSWire speaks to a specific audience of professionals. You can too. Advertise here.
The Simple SQL Injection Hack In its simplest form, this is how the SQL Injection works. It's impossible to explain this without reverting to code for just a moment. Don't worry, it will all be over soon. Suppose we enter the following string in a Username field: ' OR 1=1 The authorization SQL query that is run by the server, the command which must be satisfied to allow access, will be something along the lines of:
SELECT * FROM users WHERE username = ‘USRTEXT ' AND password = ‘PASSTEXT’ …where USRTEXT and PASSTEXT are what the user enters in the login fields of the web form. So entering `OR 1=1 — as your username, could result in the following actually being run: SELECT * FROM users WHERE username = ‘' OR 1=1 — 'AND password = '’ Two things you need to know about this: ['] closes the [username] text field. ' ' is the SQL convention for Commenting code, and everything after Comment is ignored. So the actual routine now becomes: SELECT * FROM users WHERE username = '' OR 1=1 1 is always equal to 1, last time I checked. So the authorization routine is now validated, and we are ushered in the front door to wreck havoc. Let's hope you got the gist of that, and move briskly on. Brilliant! I'm gonna go hack me a Bank! Slow down, cowboy. This half-cooked method won't beat the systems they have in place up at Citibank, evidently.
But the process does serve to illustrate just what SQL Injection is all about — injecting code to manipulate a routine via a form, or indeed via the URL. In terms of login bypass via Injection, the hoary old ' OR 1=1 is just one option. If a hacker thinks a site is vulnerable, there are cheat-sheets all over the web for login strings which can gain access to weak systems. Here are a couple more common strings which are used to dupe SQL validation routines: username field examples: •
admin'—
•
') or ('a'='a
•
”) or (“a”=”a
•
hi” or “a”=”a
… and so on. Backdoor Injection- Modules, Forums, Search etc. Hacking web forms is by no means limited exclusively to login screens. A humble search form, for instance, is necessarily tied to a database, and can potentially be used to amend database details. Using SQL commands in search forms can potentially do some extremely powerful things, like calling up usernames and passwords, searching the database field set and field
names, and amending same. Do people really get hacked through their search forms? You better believe it. And through forums, and anywhere else a user can input text into a field which interacts with the database. If security is low enough, the hacker can probe the database to get names of fields, then use commands like INSERT INTO, UNION, and so forth to get user information, change product prices, change account settings/balances, and just about anything else‌ depending on the security measures in place, database architecture and so on. So you can have security locked down at the login, but poor security on other forms can still be exploited. Unfortunately this is a real worry regarding 3rd party modules for Web CMS products which incorporate forms, and for CMS products these 3rd party modules are often the weakest links which allows hackers access to your database. Automated Injection There are tools to automate the process of SQL Injection into login and other fields. One hacker process, using a specific tool, will be to seek out a number of weak targets using Google (searching for login.asp, for instance), then insert a range of possible injection strings (like those listed above, culled from innumerable Injection cheat-sheets on the Web), add a list of proxies to cover his movements, and go play XBox while the program automates the whole injection process. Remote Injection This involves uploading malicious files to inject SQL and exploit other vulnerabilities. It's a topic which was deemed beyond the scope of this report, but you can view this PDF if you'd like to learn more. SQL Injection in the Browser Address Bar Injections can also be performed via the browser address bar. I don't mean to have a pop at Microsoft, but when it comes to such vulnerabilities, HTTP GET requests with URLs of the following form are most often held to be vulnerable: http://somesite.com/index.asp?id=10 Try adding an SQL command to the end of a URL string like this, just for kicks: http://somesite.com/index.asp?id=10 AND id=11 See if both articles come up. Don't shoot your webmaster just yet if it's your own site and you get two articles popping up: this is real low-level access to the database. But some such sites will be vulnerable. Try adding some other simple SQL commands to the end of URLs from your own site, to see what happens.
As we saw above, access to the database raises a number of interesting possibilities. The database structure can be mapped by a skilled hacker through ill-conceived visibility of error messages — this is called database footprinting — and then this knowledge of table names and so forth can be used to gain access to additional data. Revealing error messages are manna - they can carry invaluable table name and structural details. The following illustrative string is from Imperva. http://www.mydomain.com/products/products.asp?productid=123 UNION SELECT username, password FROM USERS There are vast swathes of information on SQL Injection available, here are a couple of good sources: •
GovernmentSecurity.org
•
SecurityDocs.com
Cross Site Scripting (XSS) XSS or Cross Site Scripting is the other major vulnerability which dominates the web hacking landscape, and is an exceptionally tricky customer which seems particularly difficult to stop. Microsoft, MySpace, Google… all the big cahunas have had problems with XSS vulnerabilities. This is somewhat more complicated than SQL Injection, and we'll just have a quick look to get a feel for it. XSS is about malicious (usually) JavaScript routines embedded in hyperlinks, which are used to hijack sessions, hijack ads in applications and steal personal information. Picture the scene: you're there flicking through some nameless bulletin board because, yes, you really are that lazy at work. Some friendly girl with broken English implores you to get in touch. 'Me nice gurl', she says. You've always wondered where those links actually go, so you say what the hell. You hover over the link, it looks like this in the information bar: [%63%61%74%69%6f%6e%3d%274%74%70%3a%2f%2f%77%7…] Hmmm…what the hell, let's give it a bash, you say. The one thing I really need right now is to see an ad for cheap Cialis. Maybe the linked page satisfies this craving, maybe not. Nothing dramatic happens when you click the link, at any rate, and the long day wears on. When a link in an IM, email, forum or message board is hexed like the one above, it could contain just about anything. Like this example, from SandSprite, which helps steal a session cookie, which can potentially be used
to hijack a session in a web application, or even to access user account details.
Stealing cookies is just the tip of the iceberg though — XSS attacks through links and through embedded code on a page or even a bb post can do a whole lot more, with a little imagination. XSS is mostly of concern to consumers and to developers of web applications. It's the family of security nightmares which keeps people like MySpace Tom and Mark Zuckerberg awake at night. So they're not all bad then, I suppose… For additional resources on this topic, here's a great overview of XSS (PDF) and just what can be accomplished with sneaky links. And here's an in-depth XSS video.
Authorization Bypass Authorization Bypass is a frighteningly simple process which can be employed against poorly designed applications or content management frameworks. You know how it is… you run a small university and you want to give the undergraduate students something to do. So they build a content management framework for the Mickey Bags research department. Trouble is that this local portal is connected to other more important campus databases. Next thing you know, there goes the farm Authorization bypass, to gain access to the Admin backend, can be as simple as this: •
Find weak target login page.
•
View source. Copy to notepad.
•
Delete the authorization javascript, amend a link or two.
•
Save to desktop.
•
Open on desktop. Enter anything into login fields, press enter.
•
Hey Presto.
Here's a great video of a White Hat going through the authorization-bypass process on YouTube. This was done against a small university's website. It's a two-minute process. Note that he gets into the User 1 account, which is not the Admin account in this case. Is Admin User 1 on your User table?
Google Hacking This is by far the easiest hack of all. It really is extraordinary what you can find in Google's index. And here's Newsflash #1: you can find a wealth of actual usernames and passwords using search strings. Copy and paste these into Google: inurl:passlist.txt inurl:passwd.txt …and this one is just priceless… “login: *” “password= *” filetype:xls Such strings return very random results, and are of little use for targeted attacks. Google hacking will primarily be used for finding sites with vulnerabilities. If a hacker knows that, say, SQL Server 2000 has certain exploits, and he knows a unique string pushed out by that version in results, you can hone in on vulnerable websites. For specific targets Google can return some exceptionally useful information: full server configurations, database details (so a good hacker knows what kind of injections might work), and so forth. You can find any amount of SQL database dumps as well (fooling around with a Google hack while preparing this article, I stumbled across a dump for a top-tier CMS developer's website). And a vast amount more besides. johnny.ihackstuff.com is the man to go to for Google hacks. One interesting one I toyed with invited me to the Joomla! install page for dozens of sites… people who had uploaded Joomla!, decided against installing it, and subsequently had either left the domain to rot, or else set a redirect on the page to, say, their Flickr account (in one case). Allowing anybody to walk in and run through the installer. Other query strings target unprotected email/IM archives, and all sorts of very sensitive information. What fun we can have!
Password Cracking Hashed strings can often be deciphered through 'brute forcing'. Bad news, eh? Yes, and particularly if your encrypted passwords/usernames are floating around in an unprotected file somewhere, and some Google hacker comes across it. You might think that just because your password now looks something like XWE42GH64223JHTF6533H in one of those files, it means that it can't be cracked? Wrong. Tools are freely available which will decipher a certain proportion of hashed and similarly encoded passwords.
A Few Defensive Measures •
If you utilize a web content management system, subscribe to the development blog. Update to new versions soon as possible.
•
Update all 3rd party modules as a matter of course — any modules incorporating web forms or enabling member file uploads are a potential threat. Module vulnerabilities can offer access to your full database.
•
Harden your Web CMS or publishing platform. For example, if you use WordPress, use this guide as a reference.
•
If you have an admin login page for your custom built CMS, why not call it 'Flowers.php' or something, instead of “AdminLogin.php” etc.?
•
Enter some confusing data into your login fields like the sample Injection strings shown above, and any else which you think might confuse the server. If you get an unusual error message disclosing server-generated code then this may betray vulnerability.
•
Do a few Google hacks on your name and your website. Just in case…
•
When in doubt, pull the yellow cable out! It won't do you any good, but hey, it rhymes.
UPDATE I had posted a link here to a hacking bulletin board containing specific sql injections strings etc. The link pointed to a page which listed numerous hacks targetting various CMS platforms, but containing a disproportionate number of hacks for one platform in particular. In retrospect, and following a specific complaint, I have pulled down this link. Apologies to the complainant and to anyone else who found this link to be inappropriate.
53 Reader Comments 1|
Jason — March 9, 2008 2:53 AM
I appreciate that you've presented this information in a form that less techsavvy users can understand. However, there are a few issues I have as a professional programmer with some of the solutions presented. Primarily, you make SQL injection sound like a magical breakthrough that requires some military-grade security architect to circumvent it. SQL Injection can be properly stopped simply by properly escaping your data. In an SQL string, if you wish to represent quotation marks, it must be escaped with a backslash (\' instead of ' or \" instead of ") to differentiate it from a quotation mark that would end the string. This is an oversimplification and
there are other rules, but the point is that most web scripting languages have functions that you can pass a string through to avoid the leak. In PHP, this is mysql_real_escape_string. Essentially, for each SQL query that allows any input by the user, escape that information. Also, another thing that I've found useful is to convert input data to integers when I am putting numbers into a query. For example, in the query SELECT * FROM `users` WHERE `id`=1, the 1 does not have quotes around it, so it is possible still to perform an SQL injection attack even with properly escaped data. Converting the id to an integer before it is injected will mitigate that. What Citi and other online banking sites do is not magic, it's just good programming practice. Also, your first two defense measures suggested updating versions 'as soon as possible.' In general, unless a patch is specifically fixing a large security error, this is not a good idea, because new code introduces new vulnerabilities. If you updated your codebase simply because a new version came out, what are you going to do if a major exploit is found in the new version two days later? It's better to wait a little to be sure that the new version is stable, especially if valuable information is at stake. On the topic of password cracking, one common programming practice is to use a 'salt' on whatever password is being encrypted. Hypothetically, when you come to XYs site and log in with the password 'password', and they're using MD5 encryption without using a salt, your password will be checked against the MD5ed version of 'password'... however, lets say they have a pseudorandom salt of 'Mt5y4r'. When you log in with 'password', this salt is added to your string, so it is now 'passwordMt5y4r' that is being encrypted and checked against the database. This simply means that if a hacker gains access to the password table it will take much longer for a crack to work, because they are not finding the reverse of 'password' (which would be an easy dictionary crack.) There are other benefits, and even more secure ways of implementing a salt, and http://en.wikipedia.org/wiki/Salt_(cryptography) can explain it better than I can. Thanks for your time.. this is not meant to be overly critical, this article is good overall, just trying to help out! :) 2|
ccchai — March 9, 2008 4:26 AM
Trackback from "Best resources for Web developers and designers" ( http://impressionsoft.blogspot.com/2008/03/best-resources-for-webdevelopers-and.html ) 3|
BedriftsGuiden blog — March 9, 2008 7:30 AM
Very useful info! Posting a link to this.
4|
Steph G — March 9, 2008 9:57 AM
That is exactly why i use a protection modules on my web site. I reviewed a few and went on with dotDefender for IIS. My two cents. 5|
tim — March 9, 2008 3:09 PM
If you're doing "SELECT * FROM users WHERE username = ‘USRTEXT ’ AND password = ‘PASSTEXT’" to authenticate, you've got all kinds of problems. Most importantly, it means you're storing unencrypted passwords in your database. That's even worse than SQL injection! Our operating systems have had salted, encrypted passwords for decades, and they're really easy to implement -- there's no excuse for not knowing about them. 6|
a — March 9, 2008 3:50 PM
very useful... thanks. 7|
John Conroy — March 10, 2008 8:10 AM
Thanks everyone. And great feedback Jason -- thanks for taking the time. On the subject of updating modules, yes: perhaps it's better to say that you should "update your modules", rather than say that it should be done ASAP. 8|
Carl B — March 10, 2008 4:18 PM
Thanks for a good read. You're the first one I've come across that was able to explain XSS for the simple concept that it is. 9|
Jay — March 19, 2008 1:59 AM
Great article. But wonder how many of guys see this and close the holes. Well...it worked most of the time. 10 |
Sanjeev — March 21, 2008 12:18 AM
We want partnership & advertisement with u Our concept is New Internet tricks & techniques First time in world whole keyboard is booked by AtoAll.com ( angle)for easy search. Type two times any three letters which are together on the keyboard (right to left) e.g. mmnnbb ctrl+enter for quick Web Search. This option is working from whole keyboard.
11 |
tinkertim — April 2, 2008 6:54 AM
Could you call it 'cracking' and not 'hacking'? For instance, I hack the GNU core utilities to improve them, this involves no wrong doing and helps my neighbor. Please stop saying 'hacking' when wrong doing is implied, else GNU and Kernel hackers will have to come up with a new term. This would be sad, as our motivation to do what we did was to help our hacker community. I don't care what using 'hacking' does for you SEO, consider the damage that your doing to the community that built the OS that powers this blog. You might enjoy reading this: http://www.gnu.org/philosophy/rms-hack.html Its an interview with RMS (the guy who wrote gcc and the core utilities that you now call 'Linux'). Cheers, --Tim 12 |
ACE-KING — April 7, 2008 2:16 PM
Great article , really enjoyed it. The information is rather basic but I hope all the webmasters reading this have closed any holes. It amazes me how many sites lack any real security ! 13 |
john conroy — April 14, 2008 10:50 AM
tinkertim: duly noted. 14 |
http://hackbuzz.blogspot.com/ — April 15, 2008 4:33 AM
usefull info..need to share 15 |
Anon — May 11, 2008 11:01 PM
Wow, thanks for explaining the process to a non tech. I have heard of sql injection before but didn't quite understand what it really was before reading your article. 16 |
Bard — May 24, 2008 3:19 PM
Great article. Lots of good information. I have inherited two Classic ASP/SQL 2000 web sites that have been subject to constant brutal hacking. They were poorly coded to begin with and it has been a chore getting them updated. What seems to work for me for the SQL injection, or at least the type these sites were subject to (domain/URL) has been creation and use of a 'read
only' user with stored procedures. That way the only code that can be written is what is allowed by the stored procedure. Insert, update, delete and many other commands are not allowed. I also created custom error pages and forced all query strings to be int, so there cannot be any way to get SQL data (that I know of). I also remove scripting and html from text boxes on all forms. This seems to have worked just fine so far, after months of constant backing up and restoring at least once a week on both sites, they haven't been hacked in a month, although I am logging attempts and there have been many. Anyway well written 101 article and thanks for the info! 17 |
Hami — June 30, 2008 7:16 PM
Good description mate...! Very well explained .. 18 |
Teng — July 16, 2008 4:30 AM
Nice Info! 19 |
bhushan — August 20, 2008 11:20 AM
it is really good useful, Thanx a lot... 20 |
Retag — September 1, 2008 10:18 PM
For the "Authorization Bypass" section, you do not even need to save the HTML source anymore. You can make modifications on the page if you run plugins such as Firebug on Firefox. Even the HTTP-Referer header will be correct! 21 |
Fahim — September 29, 2008 12:52 PM
there is no information to login avoiding get_magic_quotes_gpc() 22 |
dhavni — October 13, 2008 4:59 AM
i am not eable to open orkut bec in our collage there is url or page has been bloked. 23 |
A Mohamad — October 13, 2008 9:10 AM
Good article, hehehe...i can start hacking websites now :p 24 |
Jayson — October 15, 2008 7:45 AM
Very useful info. Please tell me how to brute 3 web forms (username, passwd, and form3). Most tools have 2 input form which are only username and password. Please help, just a newbie. 25 |
jun — October 23, 2008 1:41 AM
easily explained... hard to be d0ne... :p 26 |
James Lawrie — November 3, 2008 4:16 PM
Just one quick question: If you wanted to bring up two articles, I don't think http://somesite.com/index.asp?id=10 AND id=11 would work, because no article has an id 10 and an id of 11 (unless there's some dodgy database schema going on). Shouldn't it be id=10 OR id=11? 27 | PM
http://freemoneypayments.blogspot.com/ — November 3, 2008 7:05
Great article on how people hack sites. Really informative. 28 |
john conroy — November 7, 2008 9:02 AM
True for ya James -- good point-- should be OR 29 |
deepak — November 11, 2008 2:59 PM
i want to hack it completly..... 30 |
Soumik — November 11, 2008 4:27 PM
Excellent article and wonderful feedback from all. Very refreshing and simplified. 31 |
Daryl James — November 16, 2008 6:17 PM
Speaking as a pseudo-knowledgeable user, I appreciated the article...its middle-of-the-road tech language should be considered the standard that all may partake. 32 |
dk kim — November 26, 2008 12:27 AM
good. 33 |
DN — December 12, 2008 11:42 AM
Interesting article. OF course, nowadays, most websites are invulnerable to SQL injection etc, but it still gives you something to think about... 34 |
Belmos — December 17, 2008 10:17 AM
Wow, it is a interesting article. Then i want to give immune power to my websites against hackers. 35 |
jack — December 23, 2008 2:27 PM
hi...im trying to find out how to hack a certain game on byond.com/ im not doing it to screw up the game though... there are already tons of hackers on there and i want to...counterhack. i hav no idea what everything above means... cud u email me a simpler version? 36 |
Eldad — January 7, 2009 2:16 PM
Excuse me for not disclosing my email / web address to this page found on google by typing 'hacking' :) Very clear, very useful, I am not a top notch programmer and I understood. I would really appreciate a sequel explaining more about how to avoid being hacked. But for what given already, Thank you.
37 |
kai — January 16, 2009 2:07 AM
great info! Thanks! I'm a basic programmer/ web designer, so things like this are very helpful.. Thanks again! 38 |
Chris — January 21, 2009 1:30 PM
Nice article. Im a .Net programmer looking for way to secure our .NET apps, with the SQL backend. We use alot of AJAX, SOAP calls. For future, it would be great see an artcile just pertaining to .NET hacking. 39 |
gurpreet — January 24, 2009 2:03 AM
sir i cant under stand how to crack web site.please tell me initally how to hack simple sites.
40 |
Lisa — February 13, 2009 9:23 AM
Thank you. A friend's website (organization) seems to have been hacked and this article helped me understand better how I can help them. A good foundation moving forward on what/how to better protect crucial information and data. 41 |
Brian — March 26, 2009 10:51 AM
I like the article. But as I look for higher level controls for these weaknesses I am left wanting. I am looking for management level strategic policies to steer away from these problems. Right now the best policy seems to be avoid CMS and avoid SQL. That we should go back to static web pages. I am on the verge of throwing out Joomla. 42 |
Brice Dunwoodie (CMSWire Editor) — March 26, 2009 11:17 AM
@Brian We hear your complaint. I think such high level views were not part of the original article scope. What companies need to do is a mix of things, but mostly they need an IT security policy that is backed up by real practices. If you're developing software, you need defensive programming standards that strengthen security (e.g., read Making Wrong Code Look Wrong by Joel Spolksy) , security testing as part of QA and security checklists (on a technology specific basis) that must be passed before going live. This is just for starters. You say you're on the verge of throwing out Joomla!. Well, before doing that, I'd tap into the Joomla! community and get some help understanding what is and isn't a real security concern with your particular version and configuration. Assuming that you've invested a lot in your CMS infrastructure -- as most people have -- I think you can probably refine your security posture more easily than you can start from scratch with an entirely new CMS. Check out the Joomla! Security Strike Team and make personal contact with people. If you poke around a bit, I think you'll find that the resources are there for you. 43 |
Fred — May 4, 2009 4:50 AM
Excellent security article, very nice read! Hopefully many new web developers will wake up and at least escape their SQL input : ) 44 |
liam — May 11, 2009 11:25 PM
I love all of the comments that say, "please tell me how to hack website. Thank you sir" Well first thing you should do is open up a command prompt and type format c: /q... Do people think that hacking is like in the movies? You type 'hack google' in a dos prompt and then a progress bar pops up that says 'Hacking Google... 57% complete'. And then another button pops up that says, 'Secret credit card file found. Click to download'. They download it and then another button pops up that says, 'Erase tracks?'. They hit enter and make a clean get away. Here is the best way to hack websites: Enroll in college, earn a computer science degree, learn that black hat is unethical and that hard working people are behind those sites you want to 'hack'. After that, try doing something useful with your life that isn't destroying/stealing/taking from other people. After that you will know how to hack websites, but hopefully by then you are actually making a living by an ethical means and not trying to steal or destroy other peoples property. 45 |
idami — June 7, 2009 11:07 AM
Il faut dire que c'est très utile à savoir, Pas dans le but de pirater des sites, mais plutôt pour mieux se protéger contre les pirates. Mon site a deux enregistré 2 tentatives de piratage, à travers des requète SQL bizzares passées directement dans l'adresse. Après vérification, j'ai trouvé que mon site présentait quelques failles, que j'ai éliminé sur le champs, en insérant quelques instruction PHP, pour vérifier les paramètres avant de les passer à la requête SQL 46 |
Troy — June 10, 2009 7:47 PM
Thanks, I am an entry-level web designer and I think I am going to hold off on ecommerce and stick to paypal until I know what I'm dealing with...cheers 47 |
tomer — June 18, 2009 7:20 AM
I would like to share with you a tool call dotdefender - It will block all kind of web application attacks among them sql injection, cross site scripting and many more alike. 48 |
carol — June 18, 2009 9:46 PM
another good reference - http://www.amazon.com/Joomla-Web-SecurityTomCanavan/dp/1847194885/ref=sr_1_1?ie=UTF8&s=books&qid=1245350810& sr=8-1 49 |
sandeep — July 8, 2009 5:25 AM
Awesome article. People like me who are less tech savy can understand it. Those examples made my life simpler to understand and correlate things 50 |
Joe Owl — July 9, 2009 9:13 AM
You can also use automated tools to find that (Powerfuzzer http://scanner.powerfuzzer.com/ and Joomlascanner http://www.joomlascanner.com)./ Let me know your comments. 51 |
deepak — July 11, 2009 12:44 PM
yes,it was good but i want to know that how to become a hacker 52 |
Lynn Brown — July 24, 2009 1:03 AM
Ok, I'm an SEO but I'm posting just to thank you. I have a new client whose site has been hacked twice recently, and I think I now know why, looking in his control panel he has half installed or installed with admin/admin as the user/pass combination all sorts of scripts in his cpanel. Bet thats how a hacker got access.... i don't want to know how to become a hacker, would love to watch someone do it though.... for real and not on TV lol... Anyway thank you for explaining just how vulnerable websites can be. Great post. Lynny 53 |
khurram Nazir — August 28, 2009 5:39 PM
I've found with my study and work that about 67% websites are unsafe from XSS (Cross site scripting). Cool