Internet Security

Nowadays performing online banking transaction is very easy. It can be accessed anytime and anywhere. However there is also more security issue when performing this transaction. Below 10 points to remember when performing online banking.

1. Always access Bank's Internet banking by typing in the correct URL:
Never click on a link in an email to take you to a website and enter personal details either in the email or website

2. Password and PIN security:
You should always be wary if you receive unsolicited emails or calls asking you to disclose any personal details or card numbers. This information should be kept secret at all times. Be cautious about disclosing personal information to individuals you do not know. Please remember that Standard Chartered Bank would never contact you directly to ask you to disclose your PIN or all your password information.

3. If it sounds too good to be true - it probably is:
Don't be conned by convincing emails offering you the chance to make some easy money. As with most things if it looks too good to be true, it probably is! Be cautious of unsolicited emails from overseas - it is much harder to prove legitimacy of the organisations behind the emails.

Internet Explorer 7.0 vs. Safari 3.0 vs. Firefox 3.0 Comparison in security perspective

1. Cross site scripting (XSS)
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.

2. Injection flaws
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.”

3. Malicious file execution
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.

4. Insecure direct object reference
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.

Hackers have turned the harvesting of personal information from Monster.com and other large US jobsites into a lucrative black market business

A Russian gang called Phreak has created an online tool that extracts personal details from CVs posted onto sites including Monster.com, AOL Jobs, Ajcjobs.com, Careerbuilder.com, Careermag.com, Computerjobs.com, Hotjobs.com, Jobcontrolcenter.com, Jobvertise.com and Militaryhire.com. As a result the personal information (names, email addresses, home addresses and current employers) on hundreds of thousands of jobseakers has been placed at risk, according to net security firm PrevX.

Phreak has begun selling its "identity harvesting services" to fraudsters, charging $600 for data that might be applied to targeted phishing attacks, ID fraud or other nefarious purposes. Would-be clients are able to contact the gang on ICQ. For a fee the gang will filter its database for entries that refer to a particular country or particular employer.

The reliability of digital certificates and digital signatures is dependent on the authenticity of the key used to verify the signature and the reliability of the technical environment.

The utility of a digital signature as an authenticating tool is limited by the ability of the recipient to ensure the authenticity of the key used to verify the signature. For example, if the sender uses a private key to sign an unencrypted message, the receiver can verify the sender if the receiver knows the sender’s public key. To rely on the authenticity of that public key, the receiver must first retrieve it from some trusted source other than the sender. If an imposter is forging a message from the sender, he will send his own public key as well, claiming that it actually belongs to the sender. Since the imposter has the private key corresponding to the public key he sends to the receiver, when the receiver attempts to verify the signature of the forged message, it will result in a confirmation of the message’s authenticity even though it is not from the real sender.