10 reasons Why websites get HACKED.

Hi Friends Welcome Back,
For more updates join our facebook group:-

Below you will find list of top 10 web vul­ner­a­bil­i­ties clas­si­fied by OWASP, here is also descrip­tion of the prob­lem and some examples.
I will just give you the list in case you missed it before, i will not com­ment on any of these as there is already hot dis­cus­sion about this mat­ter on sev­eral sites/​forums.
So here it starts:- 
1. Cross site script­ing (XSS)
The prob­lem: The “most preva­lent and per­ni­cious” Web appli­ca­tion secu­rity vul­ner­a­bil­ity, XSS flaws hap­pen when an appli­ca­tion sends user data to a Web browser with­out first val­i­dat­ing or encod­ing the con­tent. This lets hack­ers exe­cute mali­cious scripts in a browser, let­ting them hijack user ses­sions, deface Web sites, insert hos­tile con­tent and con­duct phish­ing and mal­ware attacks.

Attacks are usu­ally exe­cuted with JavaScript, let­ting hack­ers manip­u­late any aspect of a page. In a worst-​case sce­nario, a hacker could steal infor­ma­tion and imper­son­ate a user on a bank’s Web site, accord­ing to Sny­der.

Real- ​world exam­ple: Pay­Pal was tar­geted last year when attack­ers redi­rected Pay­Pal vis­i­tors to a page warn­ing users their accounts had been com­pro­mised. Vic­tims were redi­rected to a phish­ing site and prompted to enter Pay­Pal login infor­ma­tion, Social Secu­rity num­bers and credit card details. Pay­Pal said it closed the vul­ner­a­bil­ity in June 2006.

How to pro­tect users: Use a whitelist to val­i­date all incom­ing data, which rejects any data that’s not spec­i­fied on the whitelist as being good. This approach is the oppo­site of black­list­ing, which rejects only inputs known to be bad. Addi­tion­ally, use appro­pri­ate encod­ing of all out­put data. “Val­i­da­tion allows the detec­tion of attacks, and encod­ing pre­vents any suc­cess­ful script injec­tion from run­ning in the browser,” OWASP says.

 2. Injec­tion flaws
The prob­lem: When user-​supplied data is sent to inter­preters as part of a com­mand or query, hack­ers trick the inter­preter — which inter­prets text-​based com­mands — into exe­cut­ing unin­tended com­mands. “Injec­tion flaws allow attack­ers to cre­ate, read, update, or delete any arbi­trary data avail­able to the appli­ca­tion,” OWASP writes. “In the worst-​case sce­nario, these flaws allow an attacker to com­pletely com­pro­mise the appli­ca­tion and the under­ly­ing sys­tems, even bypass­ing deeply nested fire­walled envi­ron­ments.”

Real-​world exam­ple: Russ­ian hack­ers broke into a Rhode Island gov­ern­ment Web site to steal credit card data in Jan­u­ary 2006. Hack­ers claimed theSQL injec­tion attack stole 53,000 credit card num­bers, while the host­ing ser­vice provider claims it was only 4,113.

How to pro­tect users: Avoid using inter­preters if pos­si­ble. “If you must invoke an inter­preter, the key method to avoid injec­tions is the use of safe APIs, such as strongly typed para­me­ter­ized queries and object rela­tional map­ping libraries,” OWASP writes.
3. Mali­cious file exe­cu­tion

The prob­lem: Hack­ers can per­form remote code exe­cu­tion, remote instal­la­tion of rootk­its, or com­pletely com­pro­mise a sys­tem. Any type of Web appli­ca­tion is vul­ner­a­ble if it accepts file­names or files from users. The vul­ner­a­bil­ity may be most com­mon with PHP, a widely used script­ing lan­guage for Web devel­op­ment.

Real-​world exam­ple: A teenage pro­gram­mer dis­cov­ered in 2002 that Guess​.com was vul­ner­a­ble to attacks that could steal more than 200,000 cus­tomer records from the Guess data­base, includ­ing names, credit card num­bers and expi­ra­tion dates. Guess agreed to upgrade its infor­ma­tion secu­rity the next year after being inves­ti­gated by the Fed­eral Trade Com­mis­sion.

How to pro­tect users: Don’t use input sup­plied by users in any file­name for server-​based resources, such as images and script inclu­sions. Set fire­wall rules to pre­vent new con­nec­tions to exter­nal Web sites and inter­nal sys­tems.

4. Inse­cure direct object ref­er­ence

The prob­lem: Attack­ers manip­u­late direct object ref­er­ences to gain unau­tho­rized access to other objects. It hap­pens when URLs or form para­me­ters con­tain ref­er­ences to objects such as files, direc­to­ries, data­base records or keys.

Bank­ing Web sites com­monly use a cus­tomer account num­ber as the pri­mary key, and may expose account num­bers in the Web inter­face.

“Ref­er­ences to data­base keys are fre­quently exposed,” OWASP writes. “An attacker can attack these para­me­ters sim­ply by guess­ing or search­ing for another valid key. Often, these are sequen­tial in nature.”

Real-​world exam­ple: An Aus­tralian Tax­a­tion Office site was hacked in 2000 by a user who changed a tax ID present in a URL to access details on 17,000com­pa­nies. The hacker e-​mailed the 17,000 busi­nesses to notify them of the secu­rity breach.

How to pro­tect users: Use an index, indi­rect ref­er­ence map or another indi­rect method to avoid expo­sure of direct object ref­er­ences. If you can’t avoid direct ref­er­ences, autho­rize Web site vis­i­tors before using them

5. Cross site request forgery

The prob­lem: “Sim­ple and dev­as­tat­ing,” this attack takes con­trol of victim’s browser when it is logged onto a Web site, and sends mali­cious requests to the Web appli­ca­tion. Web sites are extremely vul­ner­a­ble, partly because they tend to autho­rize requests based on ses­sion cook­ies or “remem­ber me” func­tion­al­ity. Banks are poten­tial tar­gets.

“Ninety-​nine per­cent of the appli­ca­tions on the Inter­net are sus­cep­ti­ble to cross site request forgery,” Williams says. “Has there been an actual exploit where someone’s lost money? Prob­a­bly the banks don’t even know. To the bank, all it looks like is a legit­i­mate trans­ac­tion from a logged-​in user.”

Real-​world exam­ple: A hacker known as Samy gained more than a mil­lion “friends” on MySpace​.com with a worm in late 2005, auto­mat­i­cally includ­ing the mes­sage “Samy is my hero” in thou­sands of MySpace pages. The attack itself may not have been that harm­ful, but it was said to demon­strate the power of com­bin­ing cross site script­ing with cross site request forgery. Another exam­ple that came to light one year ago exposed a Google vul­ner­a­bil­ity allow­ing out­side sites to change a Google user’s lan­guage pref­er­ences.

How to pro­tect users: Don’t rely on cre­den­tials or tokens auto­mat­i­cally sub­mit­ted by browsers. “The only solu­tion is to use a cus­tom token that the browser will not ‘remem­ber,’” OWASP writes.

6. Infor­ma­tion leak­age and improper error han­dling

The prob­lem: Error mes­sages that appli­ca­tions gen­er­ate and dis­play to users are use­ful to hack­ers when they vio­late pri­vacy or unin­ten­tion­ally leak infor­ma­tion about the program’s con­fig­u­ra­tion and inter­nal work­ings.

“Web appli­ca­tions will often leak infor­ma­tion about their inter­nal state through detailed or debug error mes­sages. Often, this infor­ma­tion can be lever­aged to launch or even auto­mate more pow­er­ful attacks,” OWASP says.

Real- ​world exam­ple: Infor­ma­tion leak­age goes well beyond error han­dling, apply­ing also to breaches occur­ring when con­fi­den­tial data is left in plain sight. The Choi­ce­Point deba­cle in early 2005 thus falls some­where in this cat­e­gory. The records of 163,000 con­sumers were com­pro­mised after crim­i­nals pre­tend­ing to be legit­i­mate Choi­ce­Point cus­tomers sought details about indi­vid­u­als listed in the company’s data­base of per­sonal infor­ma­tion. Choi­ce­Point sub­se­quently lim­ited its sales of infor­ma­tion prod­ucts con­tain­ing sen­si­tive data.

How to pro­tect users: Use a test­ing tool such as OWASP’S Web­Scarab Project to see what errors your appli­ca­tion gen­er­ates. “Appli­ca­tions that have not been tested in this way will almost cer­tainly gen­er­ate unex­pected error out­put,” OWASP writes.

7. Bro­ken authen­ti­ca­tion and ses­sion man­age­ment

The prob­lem: User and admin­is­tra­tive accounts can be hijacked when appli­ca­tions fail to pro­tect cre­den­tials and ses­sion tokens from begin­ning to end. Watch out for pri­vacy vio­la­tions and the under­min­ing of autho­riza­tion and account­abil­ity con­trols.

“Flaws in the main authen­ti­ca­tion mech­a­nism are not uncom­mon, but weak­nesses are more often intro­duced through ancil­lary authen­ti­ca­tion func­tions such as logout, pass­word man­age­ment, time­out, remem­ber me, secret ques­tion and account update,” OWASP writes.

Real- ​world exam­ple: Microsoft had to elim­i­nate a vul­ner­a­bil­ity in Hot­mail that could have let mali­cious JavaScript pro­gram­mers steal user pass­words in2002. Revealed by a net­work­ing prod­ucts reseller, the flaw was vul­ner­a­ble to e-​mails con­tain­ing Tro­jans that altered the Hot­mail user inter­face, forc­ing users to repeat­edly reen­ter their pass­words and unwit­tingly send them to hack­ers.

How to pro­tect users: Com­mu­ni­ca­tion and cre­den­tial stor­age has to be secure. The SSL pro­to­col for trans­mit­ting pri­vate doc­u­ments should be the only option for authen­ti­cated parts of the appli­ca­tion, and cre­den­tials should be stored in hashed or encrypted form.

Another tip: get rid of cus­tom cook­ies used for authen­ti­ca­tion or ses­sion man­age­ment.

8. Inse­cure cryp­to­graphic stor­age

The prob­lem: Many Web devel­op­ers fail to encrypt sen­si­tive data in stor­age, even though cryp­tog­ra­phy is a key part of most Web appli­ca­tions. Even when encryp­tion is present, it’s often poorly designed, using inap­pro­pri­ate ciphers.

“These flaws can lead to dis­clo­sure of sen­si­tive data and com­pli­ance vio­la­tions,” OWASP writes.

Real-​world exam­ple: The TJX data breach that exposed 45.7 mil­lion credit and debit card num­bers. A Cana­dian gov­ern­ment inves­ti­ga­tion faulted TJX for fail­ing to upgrade its data encryp­tion sys­tem before it was tar­geted by elec­tronic eaves­drop­ping start­ing in July 2005.
How to pro­tect users: Don’t invent your own cryp­to­graphic algo­rithms. “Only use approved pub­lic algo­rithms such as AES, RSA pub­lic key cryp­tog­ra­phy, and SHA-​256 or bet­ter for hash­ing,” OWASP advises.

Fur­ther­more, gen­er­ate keys offline, and never trans­mit pri­vate keys over inse­cure chan­nels.

9. Inse­cure com­mu­ni­ca­tions

The prob­lem: Sim­i­lar to No. 8, this is a fail­ure to encrypt net­work traf­fic when it’s nec­es­sary to pro­tect sen­si­tive com­mu­ni­ca­tions. Attack­ers can access unpro­tected con­ver­sa­tions, includ­ing trans­mis­sions of cre­den­tials and sen­si­tive infor­ma­tion. For this rea­son, PCI stan­dards require encryp­tion of credit card infor­ma­tion trans­mit­ted over the Inter­net.

Real-​world exam­ple: TJX again. Inves­ti­ga­tors believe hack­ers used a telescope-​shaped antenna and lap­top com­puter to steal data exchanged wire­lessly between portable price-​checking devices, cash reg­is­ters and store com­put­ers, the Wall Street Jour­nal reported.

“The $17.4-billion retailer’s wire­less net­work had less secu­rity than many peo­ple have on their home net­works,” the Jour­nal wrote. TJX was using the WEPencod­ing sys­tem, rather than the more robust WPA.

How to pro­tect users: Use SSL on any authen­ti­cated con­nec­tion or dur­ing the trans­mis­sion of sen­si­tive data, such as user cre­den­tials, credit card details, health records and other pri­vate infor­ma­tion. SSL or a sim­i­lar encryp­tion pro­to­col should also be applied to client, part­ner, staff and admin­is­tra­tive access to online sys­tems. Use trans­port layer secu­rity or pro­to­col level encryp­tion to pro­tect com­mu­ni­ca­tions between parts of your infra­struc­ture, such as Web servers and data­base sys­tems.

10. Fail­ure to restrict URL access

The prob­lem: Some Web pages are sup­posed to be restricted to a small sub­set of priv­i­leged users, such as admin­is­tra­tors. Yet often there’s no real pro­tec­tion of these pages, and hack­ers can find the URLs by mak­ing edu­cated guesses. Say a URL refers to an ID num­ber such as “123456.” A hacker might say ‘I won­der what’s in 123457?’ Williams says.

The attacks tar­get­ing this vul­ner­a­bil­ity are called forced brows­ing, “which encom­passes guess­ing links and brute force tech­niques to find unpro­tected pages,” OWASP says.

Real-​world exam­ple: A hole on the Mac­world Con­fer­ence & Expo Web site this year let users get “Plat­inum” passes worth nearly $1,700 and spe­cial access to a Steve Jobs keynote speech, all for free. The flaw was code that eval­u­ated priv­i­leges on the client but not on the server, let­ting peo­ple grab free passes via JavaScript on the browser, rather than the server.

How to pro­tect users: Don’t assume users will be unaware of hid­den URLs. All URLs and busi­ness func­tions should be pro­tected by an effec­tive access con­trol mech­a­nism that ver­i­fies the user’s role and priv­i­leges. “Make sure this is done … every step of the way, not just once towards the begin­ning of any multi-​step process,’ OWASP advises.

Popular Posts