Google Dork:
inurl:”id=” & intext:”Warning: mysql_fetch_assoc()
inurl:”id=” & intext:”Warning: mysql_fetch_array()
inurl:”id=” & intext:”Warning: mysql_num_rows()
inurl:”id=” & intext:”Warning: session_start()
inurl:”id=” & intext:”Warning: getimagesize()
inurl:”id=” & intext:”Warning: is_writable()
inurl:”id=” & intext:”Warning: getimagesize()
inurl:”id=” & intext:”Warning: Unknown()
inurl:”id=” & intext:”Warning: session_start()
inurl:”id=” & intext:”Warning: mysql_result()
inurl:”id=” & intext:”Warning: pg_exec()
inurl:”id=” & intext:”Warning: mysql_result()
inurl:”id=” & intext:”Warning: mysql_num_rows()
inurl:”id=” & intext:”Warning: mysql_query()
inurl:”id=” & intext:”Warning: array_merge()
inurl:”id=” & intext:”Warning: preg_match()
inurl:”id=” & intext:”Warning: ilesize()
inurl:”id=” & intext:”Warning: filesize()
inurl:”id=” & intext:”Warning: require()

Thanks:Prens
Download: Video + tool
blind_sql.rar
http://rapidshare.com/files/312860013/blind_sql.rar

What can you do with a pressure-sensitive keyboard? That’s what Microsoft asked 40 teams. SafeLock’s one answer: It doesn’t just know your password, but how you type it, biometrically authenticating you without creepier probes.

Denial of Service (DoS) and distributed Denial of Service (DDoS) attacks involve an attempt to make a computer resource unavailable to its intended users. This may simply be for malicious purposes as is often the case when big commercial or famous web sites undergo a DDoS attack. However, it is also possible to exploit the system’s response to such an attack to break system firewalls, access virtual private networks, and to access other private resources. A DoS attack can also be used to affect a complete network or even a whole section of the Internet.

Commonly, attack involves simply saturating the target machine with external internet requests. In the case of a DDoS attack the perpetrator recruits other unwitting computers into a network and uses a multitude of machines to mount the attack. The result is that the resource, whether it is a website, an email server, or a database, cannot respond to legitimate traffic in a timely manner and so essentially becomes unavailable to users.

Methods for configuring a network to filter out known DoS attack software and to recognize some of the traffic patterns associated with a mounting DoS attack are available. However, current filters usually rely on the computer being attacked to check whether or not incoming information requests are legitimate or not. This consumes its resources and in the case of a massive DDoS can compound the problem.

Now, computer engineers John Wu, Tong Liu, Andy Huang, and David Irwin of Auburn University have devised a filter to protect systems against DoS attacks that circumvents this problem by developing a new passive protocol that must be in place at each end of the connection: user and resource.

Their protocol – Identity-Based Privacy-Protected Access Control Filter (IPACF) – blocks threats to the gatekeeping computers, the Authentication Servers (AS), and so allows legitimate users with valid passwords to access private resources.

The user’s computer has to present a filter value for the server to do a quick check. The filter value is a one-time secret that needs to be presented with the pseudo ID. The pseudo ID is also one-time use. Attackers cannot forge either of these values correctly and so attack packets are filtered out.

One potential drawback of the added layer of information transfer required for checking user requests is that it could add to the resources needed by the server. However, the researchers have tested how well IPACF copes in the face of a massive DDoS attacks simulated on a network consisting of 1000 nodes with 10 gigabits per second bandwidth. They found that the server suffers little degradation, negligible added information transfer delay (latency) and minimal extra processor usage even when the 10 Gbps pipe to the authentication server is filled with DoS packets. Indeed, the IPACF takes just 6 nanoseconds to reject a non-legitimate information packet associated with the DoS attack.

The Top 10 Web Application security vulnerabilities

This and the next series of blog entries will highlight the Top 10 most critical web application security vulnerabilities identified by the Open Web Application Security Project (OWASP).

You can use OWASP’s WebGoat to learn more about the OWASP Top Ten security vulnerabilties. WebGoat is an example web application, which has lessons showing “what not to do code”, how to exploit the code, and corrected code for each vulnerability.

You can use the OWASP Enterprise Security API Toolkit to protect against the OWASP Top Ten security vulnerabilties.

The ESAPI Swingset is a web application which demonstrates the many uses of the Enterprise Security API.

OWASP Top 10 number 1: XSS = Cross Site Scripting

Cross Site Scripting (XSS) is one of the most common security problems in today’s web applications. According to the SANS Top Cyber Security Risks, 60% of the total attack attempts observed on the Internet are against Web applications and SQL injection and Cross-Site Scripting account for more than 80% of the vulnerabilities being discovered. You are at risk of an XSS attack any time you put content that could contain scripts from someone un-trusted into your web pages.
There are 3 types of cross site scripting:

• Reflected XSS: is when an html page reflects user input data, e.g. from HTTP query parameters or a HTML form, back to the browser, without properly sanitizing the response. Below is an example of this in a servlet:

 out.writeln(“You searched for: “+request.getParameter(“query”);

• Stored XSS: is when an Attacker’s input script is stored on the server (eg a database) and later displayed in the web server html pages, without proper HTML filtering. Examples of this are in blogs, or forums where users can input data that will be displayed to others. Below is an example of this in a servlet data is retrieved from the database and returned in the HTML page without any validation:

out.writeln("<tr><td>" + guest.name + "<td>" + guest.comment);

• DOM XSS: is when JavaScript uses input data or data from the server to write dynamic HTML (DOM) elements, again without HTML sanitizing/escaping/filtering.

XSS can be used to:

• deface web pages
• hijack user sessions
• conduct phishing attacks
• execute malicious code in the context of the user’s session
• spread malware

Protecting against XSS

To protect against XSS all the parameters in the application should be validated and/or encoded before being output in HTML pages.

• Always validate on the server side for data integrity and security:
  • Validate all input data to the application:
  • Validate for type, format, length, range, and context before storing or displaying
  • Use white-listing (what is allowed), reject if invalid, instead of filtering out black-list (what is not allowed)
• Output encoding:
  • Explicitly set character encoding for all web pages (ISO-8859-1 or UTF 8):
    <%@ page contentType=”text/html;charset=ISO-8859-1″ language=”java” %>
  • all user supplied data should be HTML or XML entity encoded before rendering

Java specific Protecting against XSS

Validating Input with Java

• You can use Java regular expressions to validate input, this example from WebGoat allows whitespace, a-zA-Z_0-9, and the characters – and ,

String regex = "[\s\w-,]*";
Pattern pattern = Pattern.compile(regex);
validate(stringToValidate, pattern);

• Use Framework (Struts, JSF, Spring…) validators. With Java EE 6 you can use the Bean Validation Framework to centrally define validation constraints on model objects and with JSF 2.0 to extend model validation to the UI. For example here is a JSF 2.0 input field:

<h:inputText id="creditCard" value="#{booking.creditCardNumber}"/>

• Here is the JSF 2.0 booking Managed Bean using the Bean Validation Framework :

@ManagedBean
public class Booking {
 ...
 @NotNull(message = "Credit card number is required")
 @Size(min = 16, max = 16,
 message = "Credit card number must 16 digits long")
 @Pattern(regexp = "^\d*$",
 message = "Credit card number must be numeric")
 public String getCreditCardNumber() {
 return creditCardNumber;
 }
}

• In addition there are new JSF 2.0 Validators:
  • <f:validateBean> is a validator that delegates the validation of the local value to the Bean Validation API.
  • <f:validateRequired> provides required field validation.
  • <f:validateRegexp> provides regular expression-based validation
• Use the OWASP Enterprise Security API Java Toolkit’s Validator interface:

ESAPI.validator().getValidInput(String context,String input,String type,int maxLength,
   boolean allowNull,ValidationErrorList errorList)

• ESAPI.validator().getValidInput() returns canonicalized and validated input as a String. Invalid input will generate a descriptive ValidationErrorList, and input that is clearly an attack will generate a descriptive IntrusionException.

Output Encoding with Java

• You can use Struts output mechanisms such as <bean:write… >, or use the default JSTLescapeXML=”true” attribute in <c:out … >
• You can use the OWASP Enterprise Security API Java Toolkit’s ESAPI Encoder.encodeForHTML()method to encode data for use in HTML content. The encodeForHTML() method uses a “whitelist” HTML entity encoding algorithm to ensure that encoded data can not be interpreted as script. This call should be used to wrap any user input being rendered in HTML element content. For example:

Recently I was doing a little work for a client who has MyISAM tables with many columns (the same one Peter wrote about recently). The client’s performance is suffering in part because of the number of columns, which is over 200. The queries are generally pretty simple (sums of columns), but they’re ad-hoc (can access any columns) and it seems tailor-made for a column-oriented database.

I decided it was time to actually give Infobright a try. They have an open-source community edition, which is crippled but not enough to matter for this test. The “Knowledge Grid” architecture seems ideal for the types of queries the client runs. But hey, why not also try MonetDB, another open-source column-oriented database I’ve been meaning to take a look at?

What follows is not a realistic benchmark, it’s not scientific, it’s just some quick and dirty tinkering. I threw up an Ubuntu 9.04 small server on Amazon. (I used this version because there’s a .deb of MonetDB for it). I created a table with 200 integer columns and loaded it with random numbers between 0 and 10000. Initially I wanted to try with 4 million rows, but I had trouble with MonetDB — there was not enough memory for this. I didn’t do anything fancy with the Amazon server — I didn’t fill up the /mnt disk to claim the bits, for example. I used default tuning, out of the box, for all three databases.

The first thing I tried doing was loading the data with SQL statements. I wanted to see how fast MyISAM vs. MonetDB would interpret really large INSERT statements, the kind produced by mysqldump. But MonetDB choked and told me the number of columns mismatched. I found reference to this on the mailing list, and skipped that. I used LOAD DATA INFILE instead (MonetDB’s version of that is COPY INTO). This is the only way to get data into Infobright, anyway.

The tests

I loaded 1 million rows into the table. Here’s a graph of the times (smaller is better):

MyISAM took 88 seconds, MonetDB took 200, and Infobright took 486. Here’s the size of the resulting table on disk (smaller is better):

MyISAM is 787MB, MonetDB is 791MB, and Infobright is 317MB. Next I ran three queries:

Graphs of query performance time for all three databases are really not very helpful, because MyISAM is so much slower that you can’t see the graphs for the others. So I’ll give the numbers and then omit MyISAM from the graphs. Here are the numbers for everything I measured:

And here is a graph of Infobright duking it out with MonetDB on the three queries I tested (shorter bar is better):

I ran each query a few times, discarded the first run, and averaged the next three together.

Notes on Infobright

A few miscellaneous notes: don’t forget that Infobright is not just a storage engine plugged into MySQL. It’s a complete server with a different optimizer, etc. This point was hammered home during the LOAD DATA INFILE, when I looked to see what was taking so long (I was tempted to use oprofile and see if there are sleep() statements). What did I see in ‘top’ but a program called bhloader. This bhloader program was the only thing doing anything; mysqld wasn’t doing a thing. LOAD DATA INFILE in Infobright isn’t what it seems to be. Otherwise, Infobright behaved about as I expected it to; it seemed pretty normal to a MySQL guy.

Notes on MonetDB

MonetDB was a bit different. I had to be a bit resourceful to get everything going. The documentation was for an old version, and was pretty sparse. I had to go to the mailing lists to find the correct COPY syntax — it wasn’t that listed in the online manual. And there were funny things like a “merovingian” process (think “angel”) that had to be started before the server would start, and I had to destroy the demo database and recreate it before I could start it as shown in the tutorials.

MonetDB has some unexpected properties; it is not a regular RDBMS. Still, I’m quite impressed by it in some ways. For example, it seems quite nicely put together, and it’s not at all hard to learn.

It doesn’t really “speak SQL” — it speaks relational algebra, and the SQL is just a front-end to it. You can talk XQuery to it, too. I’m not sure if you can talk dirty to it, but you can sure talk nerdy to it: you can, should you choose to, give it instructions in MonetDB Assembly Language (MAL), the underlying language. An abstracted front-end is a great idea; MySQL abstracts the storage backend, but why not do both? Last I checked, Drizzle is going this direction, hurrah!

EXPLAIN is enlightening and frightening! You get to see the intermediate code from the compiler. The goggles, they do nothing!

From what I was able to learn about MonetDB in an hour, I believe it uses memory-mapped files to hold the data in-memory. If this is true, it explains why I couldn’t load 4 million rows into it (this was a 32-bit Amazon machine).

The SQL implementation is impressive. It’s a really solid subset of SQL:2003, much more than I expected. It even has CTEs, although not recursive ones. (No, there is no REPLACE, and there is no INSERT/ON DUPLICATE KEY UPDATE.) I didn’t try the XQuery interface.

Although I didn’t try it out, there are what looks like pretty useful instrumentation interfaces for profiling, debugging and the like. The query timer is in milliseconds (why doesn’t mysql show query times in microseconds? I had to resort to Perl + Time::HiRes for timing the Infobright queries).

I think it can be quite useful. However, I’m not quite sure it’s useful for “general-purpose” database use — there are a number of limitations (concurrency, for one) and it looks like it’s still fairly experimental.

via Quick comparison of MyISAM, Infobright, and MonetDB.

SQL WHERE clause optimization is important to get maximum performance from a query. If an index exists on a column you obviously want the query to use it.

In this article, I explain how to reduce risk of table or index scans by paying close attention to the way the conditions are formulated.

A term that is often used is “SARGable”. This basically refers to a condition in a WHERE clause that is able to use an index if one exists.

Examples of SARGable conditions are: A = x, B LIKE ‘AB%’, C IN (x, y, z). In each of these the optimizer is able to use an index. Examples of Non-SARGable conditions are: A <> x, B LIKE ‘%AB’, C NOT IN (x, y, z).

If you think about each of these it should be obvious why an index cannot be used. To explain why B LIKE ‘%AB’ is bad, I like to use the analogy of a large dictionary. If you know what letters the word starts with you can find it very quickly. If you only know what letters it ends with you have no option but to read the entire dictionary and check every single word.

You should also avoid using NOT in your WHERE clauses. NOT IN, NOT LIKE and IS NOT NULL perform a scan for exactly the reasons given above. The exception may be NOT EXISTS, which can perform very well for many queries.

One very common mistake is to use functions in such a way that a scan is performed. A condition of the form WHERE Fn(A) = x will not use an index on A, as the function has to be applied to this column in every row before it can be compared with x.

This needs an example to explain properly: suppose you want to match rows added in the last 5 days. I often see this written as follows:

SELECT blah FROM table1 WHERE DATEADD(day, 5, CreateDate) > GETDATE() This should be rewritten as follows:

SELECT blah FROM table1 WHERE CreateDate > DATEADD(day, -5, GETDATE()) There may be situations in which use of a function is unavoidable. In this case you can add a computed column that uses the function, add an index to the computed column, and refer to the computed column directly in the query.

Hello ,

below is some links to crack md5 password hashes online , i will keep this post updated with all online links for cracking md5.

http://gdataonline.com
http://md5.rednoize.com
http://ice.breaker.free.fr
http://www.milw0rm.com/md5/
http://shm.hard-core.pl/md5/
http://www.hashchecker.com
http://lasecwww.epfl.ch/%7Eoechslin/projects/ophcrack/
http://md5.benramsey.com
http://md5.altervista.org
http://shm.hard-core.pl
http://plain-text.info
http://www.passcracking.ru/
http://www.securitystats.com/tools/hashcrack.php
http://www.xmd5.org/index_en.htm

Hello ,

i have created a small bash script to backup complete mysql server and then restore it. you can download the script and configure it as per your need.

Download :

      mysql-backup.sh         29-Apr-2009 08:31  488
      mysql-restore.sh        29-Apr-2009 08:31  1.0K

you need to change permissions for this script to be executed change permissions using :

chmod +x mysql-backup.sh

chmod +x mysql-restore.sh

This script requres mysql server, mysql clinet  and mysqldump to take backup of databases and then to restore it ,

Please post you feedback if you got any problem using this script please comment below .

Hello guys ,

i hope most of you have subversion installed and running , and you might have got chance        to  take backup of you subversion repositories.

i have created couple of scripts that can take mass backup of all repositores in your   subversion repositories parent directory also the other script restore all repositories , all you  need is to change path for backup place and your repositores folder and then enjoy while this script take backup of each repository automatically it saves a lot of time.

Download Both scripts :

Backup.sh

Restore.sh

Below is step by step procedure on how to use this script :

Please if you modify it don’t remove my name or links

Step 1 ) upload backup.sh to you subversion server ,

Step 2) configure backup.sh according to your server requirements

Step 3) modify permissions for script using :

chmod +x backup.sh

Step 4) start the backup using : (* you should have permissions to directories on server where your repo exists)

sh backup.sh

Step 5) check backup logs using :

tail -f  {logfilepathhere}

Step 6)  Now Backup completed so you can compress backups files using :

tar cfz subversion_backup.tar.gz /home/svn/backups/full

Step 7) Move backup to new server where you want to take your svn or to some safe place

Step Start the restore process & upload restore.sh

Step 9) config paths in restore.sh as in step 2

Step 10) change permission of it using :

chmod +x restore.sh

Step 11) Execute the restore script :

sh restore.sh

Step 12) Every thing is restored you may go to bed for sleep now

Enjoy the script and do post your feedback , if anyone need subversion installation or backup or any other professional service you may contact me adeel.ahmad+hackinggurus at networkncc.com .

1. Cross site scripting (XSS)

The problem: The “most prevalent and pernicious” Web application security vulnerability, XSS flaws happen when an application sends user data to a Web browser without first validating or encoding the content. This lets hackers execute malicious scripts in a browser, letting them hijack user sessions, deface Web sites, insert hostile content and conduct phishing and malware attacks.

Attacks are usually executed with JavaScript, letting hackers manipulate any aspect of a page. In a worst-case scenario, a hacker could steal information and impersonate a user on a bank’s Web site, according to Snyder.

Real-world example: PayPal was targeted last year when attackers redirected PayPal visitors to a page warning users their accounts had been compromised. Victims were redirected to a phishing site and prompted to enter PayPal login information, Social Security numbers and credit card details. PayPal said it closed the vulnerability in June 2006.

How to protect users: Use a whitelist to validate all incoming data, which rejects any data that’s not specified on the whitelist as being good. This approach is the opposite of blacklisting, which rejects only inputs known to be bad. Additionally, use appropriate encoding of all output data. “Validation allows the detection of attacks, and encoding prevents any successful script injection from running in the browser,” OWASP says.

2. Injection flaws

The problem: When user-supplied data is sent to interpreters as part of a command or query, hackers trick the interpreter — which interprets text-based commands — into executing unintended commands. “Injection flaws allow attackers to create, read, update, or delete any arbitrary data available to the application,” OWASP writes. “In the worst-case scenario, these flaws allow an attacker to completely compromise the application and the underlying systems, even bypassing deeply nested firewalled environments.”

Real-world example: Russian hackers broke into a Rhode Island government Web site to steal credit card data in January 2006. Hackers claimed the SQL injection attack stole 53,000 credit card numbers, while the hosting service provider claims it was only 4,113.

How to protect users: Avoid using interpreters if possible. “If you must invoke an interpreter, the key method to avoid injections is the use of safe APIs, such as strongly typed parameterized queries and object relational mapping libraries,” OWASP writes.

3. Malicious file execution

The problem: Hackers can perform remote code execution, remote installation of rootkits, or completely compromise a system. Any type of Web application is vulnerable if it accepts filenames or files from users. The vulnerability may be most common with PHP, a widely used scripting language for Web development.

Real-world example: A teenage programmer discovered in 2002 that Guess.com was vulnerable to attacks that could steal more than 200,000 customer records from the Guess database, including names, credit card numbers and expiration dates. Guess agreed to upgrade its information security the next year after being investigated by the Federal Trade Commission.

How to protect users: Don’t use input supplied by users in any filename for server-based resources, such as images and script inclusions. Set firewall rules to prevent new connections to external Web sites and internal systems.

4. Insecure direct object reference

The problem: Attackers manipulate direct object references to gain unauthorized access to other objects. It happens when URLs or form parameters contain references to objects such as files, directories, database records or keys.

Banking Web sites commonly use a customer account number as the primary key, and may expose account numbers in the Web interface.

“References to database keys are frequently exposed,” OWASP writes. “An attacker can attack these parameters simply by guessing or searching for another valid key. Often, these are sequential in nature.”

Real-world example: An Australian Taxation Office site was hacked in 2000 by a user who changed a tax ID present in a URL to access details on 17,000 companies. The hacker e-mailed the 17,000 businesses to notify them of the security breach.

How to protect users: Use an index, indirect reference map or another indirect method to avoid exposure of direct object references. If you can’t avoid direct references, authorize Web site visitors before using them

5. Cross site request forgery

The problem: “Simple and devastating,” this attack takes control of victim’s browser when it is logged onto a Web site, and sends malicious requests to the Web application. Web sites are extremely vulnerable, partly because they tend to authorize requests based on session cookies or “remember me” functionality. Banks are potential targets.

“Ninety-nine percent of the applications on the Internet are susceptible to cross site request forgery,” Williams says. “Has there been an actual exploit where someone’s lost money? Probably the banks don’t even know. To the bank, all it looks like is a legitimate transaction from a logged-in user.”

Real-world example: A hacker known as Samy gained more than a million “friends” on MySpace.com with a worm in late 2005, automatically including the message “Samy is my hero” in thousands of MySpace pages. The attack itself may not have been that harmful, but it was said to demonstrate the power of combining cross site scripting with cross site request forgery. Another example that came to light one year ago exposed a Google vulnerability allowing outside sites to change a Google user’s language preferences.

How to protect users: Don’t rely on credentials or tokens automatically submitted by browsers. “The only solution is to use a custom token that the browser will not ‘remember,’” OWASP writes.

6. Information leakage and improper error handling

The problem: Error messages that applications generate and display to users are useful to hackers when they violate privacy or unintentionally leak information about the program’s configuration and internal workings.

“Web applications will often leak information about their internal state through detailed or debug error messages. Often, this information can be leveraged to launch or even automate more powerful attacks,” OWASP says.

Real-world example: Information leakage goes well beyond error handling, applying also to breaches occurring when confidential data is left in plain sight. The ChoicePoint debacle in early 2005 thus falls somewhere in this category. The records of 163,000 consumers were compromised after criminals pretending to be legitimate ChoicePoint customers sought details about individuals listed in the company’s database of personal information. ChoicePoint subsequently limited its sales of information products containing sensitive data.

How to protect users: Use a testing tool such as OWASP’S WebScarab Project to see what errors your application generates. “Applications that have not been tested in this way will almost certainly generate unexpected error output,” OWASP writes.

7. Broken authentication and session management

The problem: User and administrative accounts can be hijacked when applications fail to protect credentials and session tokens from beginning to end. Watch out for privacy violations and the undermining of authorization and accountability controls.

“Flaws in the main authentication mechanism are not uncommon, but weaknesses are more often introduced through ancillary authentication functions such as logout, password management, timeout, remember me, secret question and account update,” OWASP writes.

Real-world example: Microsoft had to eliminate a vulnerability in Hotmail that could have let malicious JavaScript programmers steal user passwords in 2002. Revealed by a networking products reseller, the flaw was vulnerable to e-mails containing Trojans that altered the Hotmail user interface, forcing users to repeatedly reenter their passwords and unwittingly send them to hackers.

How to protect users: Communication and credential storage has to be secure. The SSL protocol for transmitting private documents should be the only option for authenticated parts of the application, and credentials should be stored in hashed or encrypted form.

Another tip: get rid of custom cookies used for authentication or session management.

8. Insecure cryptographic storage

The problem: Many Web developers fail to encrypt sensitive data in storage, even though cryptography is a key part of most Web applications. Even when encryption is present, it’s often poorly designed, using inappropriate ciphers.

“These flaws can lead to disclosure of sensitive data and compliance violations,” OWASP writes.

Real-world example: The TJX data breach that exposed 45.7 million credit and debit card numbers. A Canadian government investigation faulted TJX for failing to upgrade its data encryption system before it was targeted by electronic eavesdropping starting in July 2005.
How to protect users: Don’t invent your own cryptographic algorithms. “Only use approved public algorithms such as AES, RSA public key cryptography, and SHA-256 or better for hashing,” OWASP advises.

Furthermore, generate keys offline, and never transmit private keys over insecure channels.

9. Insecure communications

The problem: Similar to No. 8, this is a failure to encrypt network traffic when it’s necessary to protect sensitive communications. Attackers can access unprotected conversations, including transmissions of credentials and sensitive information. For this reason, PCI standards require encryption of credit card information transmitted over the Internet.

Real-world example: TJX again. Investigators believe hackers used a telescope-shaped antenna and laptop computer to steal data exchanged wirelessly between portable price-checking devices, cash registers and store computers, the Wall Street Journal reported.

“The $17.4-billion retailer’s wireless network had less security than many people have on their home networks,” the Journal wrote. TJX was using the WEP encoding system, rather than the more robust WPA.

How to protect users: Use SSL on any authenticated connection or during the transmission of sensitive data, such as user credentials, credit card details, health records and other private information. SSL or a similar encryption protocol should also be applied to client, partner, staff and administrative access to online systems. Use transport layer security or protocol level encryption to protect communications between parts of your infrastructure, such as Web servers and database systems.

10. Failure to restrict URL access

The problem: Some Web pages are supposed to be restricted to a small subset of privileged users, such as administrators. Yet often there’s no real protection of these pages, and hackers can find the URLs by making educated guesses. Say a URL refers to an ID number such as “123456.” A hacker might say ‘I wonder what’s in 123457?’ Williams says.

The attacks targeting this vulnerability are called forced browsing, “which encompasses guessing links and brute force techniques to find unprotected pages,” OWASP says.

Real-world example: A hole on the Macworld Conference & Expo Web site this year let users get “Platinum” passes worth nearly $1,700 and special access to a Steve Jobs keynote speech, all for free. The flaw was code that evaluated privileges on the client but not on the server, letting people grab free passes via JavaScript on the browser, rather than the server.

How to protect users: Don’t assume users will be unaware of hidden URLs. All URLs and business functions should be protected by an effective access control mechanism that verifies the user’s role and privileges. “Make sure this is done … every step of the way, not just once towards the beginning of any multi-step process,’ OWASP advises.