Leaderboard

Web Developers, much of my posting to date has covered protecting yourself. Lets talk about protecting your customer and their users. I cannot state this any stronger, Strong Passwords! If it takes little effort to break a password than the site you built can be hi-jacked to pass out malware. Database design, consider making it a tiered design. Sensitive data in a red zone, encrypted and password protected with strict access permissions. Less sensitive data in a Yellow zone that has lesser protection and more access and simple stuff in a green zone with just password protection and general permissions. If you use look-up tables that state that "2 = married with children", that is a look-up table and needs liuttle protection. But all sensitive data should be encrypted so that if adversaries do get to it... they can't read it. Be aware of SQL Injection attacks. If you allow data to be added to a website, make sure it is checked. If you allow basic comments with no security, an adversary could insert JavaScript into that comment that does really bad things. Malware Detection - Discovering Cross-Site Scripting Attacks Watering Hole Attacks. I think LastLine blog defined it rather well: "In a network watering hole attack, cybercriminals set traps in websites that their target victims are known to frequent. Often the booby-trapped websites are smaller, niche sites that tend to have limited security. These sites can include business partner sites or small websites that provide specific products, services, or information to the target company or industry. When visited, the compromised website infects the target end-users computer or device with keyloggers, ransomware, and other types of malware." The issue here is really about protecting web sites you build from being the water holes that infects your customers users. Network Security and Watering Hole Attacks As I come across tips for securing your web sites, I will expand this thread.

No. To track a users friends, that would probably be best handled in it's own table. So I would have perhaps a 'friends' table that would have perhaps three fields: user id friend user id date of frienship ... Something like that. So for each friend a user has, a new record (row) would be created. And then, you would apply an index to the field 'user id' ... for speed. Stef