Security Zone

Information Security Discussion and Risk Advisory Blog!

Employee Non Disclosure Agreement (NDA) Template

Please Click Here to download Employee Non Disclosure Agreement (NDA) Template

Replace highlighted text with your company details, employee name etc.

The template is not specific to any sector, it can be used within any organization.

List of Common Ports

List of all the TCP and UDP ports with highlighted Trojan and Worm Ports.

Excel file is search-able and sortable Click Here to Download Excel File

Common Port Cheat Sheet Chick Here to Download

Sample Screenshot

port list.png

Trace Email - Detailed Tutorial w/ Images

The purpose of this guide is to show the process involved in tracing an email. The first step required to tracing an email is finding out the headers of the email. What are headers? Email headers are lines added at the top of an email message that are used by servers as the email goes on route to get delivered. Generally email clients only show the standard To, From, and Subject headers, but there are more.

1) Enabling Email Headers

Enabling Email Headers For Gmail

Step 1:Once Logged into your Gmail Account open the Email whose headers you want to view. Click on the “More Options” link in the message next to the date of the email.



Step 2: Now click the “Show Original” link.



Step 3: This link will popup a new window the headers and the body of the message.

Enabling Email Headers For Hotmail

Step 1:Once logged in, click on the “Options” link in the upper navigation bar.



Step 2: Now click on the “Mail Display Settings” link.



Step 3: Change the “Message Headers” option to “Full” and click ok.



Step 4: Go to your inbox and open any one of your email. You emails show now contain additional headers.

Enabling Email Headers For Yahoo



Step 1:Once logged in, click on the “Options” link in the upper navigation bar.



Step 2: Now click on the “General Preferences” link.



Step 3: In the paragraph titled Messages and locate the “Headers” heading and select “All“.



Step 4: Go to your inbox and open any one of your email. You emails show now contain additional headers.

2) Understanding Email Headers



In this example the “Sender” located at sender@exampleuniversity.edu want to send an email to “Receiver” located at receiver@exampleisp.com. The sender composes his email at his workstation in the university’s computer lab (lab.exampleuniversity.edu). Once completed the email message is passed to the university’s mail server called mail.exampleuniversity.com. The mail server seeing that it has a message for receiver@exampleisp.com, contacts someisp.com mail server and delivers the email to it. The email is stored on someisp.com server until Receiver logs on to check his/her inbox.

In this example, four headers will be added to the email message. This first header is generated by email client on lab.exampleuniversity.edu when forwarding it to the mail server at mail.exampleuniversity.edu.



The following header is added when mail.exampleuniversity.edu transmits the message to mail.exampleisp.com.


The following header is added when mail.exampleisp.com stores the message on the server for Reciever.



The following header is added when Reciever downloads the email from home machine called reciever.local.

3) Tracking The Orginal Sender

The easiest way for finding the original sender is by looking for the X-Originating-IP header, this header is important since it tells you the IP Address of the computer that had sent the email. If you can not find the X-Originating-IP header then you will have to sift through the Received headers to find the sender’s ip.



Once the email sender’s ip is found go to http://www.arin.net/ to begin a search.



Now click on the “NET-24-16-0-0-1” link.



Scroll down the page untill you find the OrgAbuseEmail field.



Remember to include all the headers of the email along with an attached copy when filling a complaint.

Cross Site Scripting - XSS

1. What is Cross Site Scripting?

Cross Site Scripting (or XSS) is one of the most common application-layer web attacks. XSS commonly targets scripts embedded in a page which are executed on the client-side (in the user’s web browser) rather than on the server-side. XSS in itself is a threat which is brought about by the internet security weaknesses of client-side scripting languages, with HTML and JavaScript (others being VBScript, ActiveX, HTML, or Flash) as the prime culprits for this exploit. The concept of XSS is to manipulate client-side scripts of a web application to execute in the manner desired by the malicious user. Such a manipulation can embed a script in a page which can be executed every time the page is loaded, or whenever an associated event is performed.

A basic example of XSS is when a malicious user injects a script in a legitimate shopping site URL which in turn redirects a user to a fake but identical page. The malicious page would run a script to capture the cookie of the user browsing the shopping site, and that cookie gets sent to the malicious user who can now hijack the legitimate user’s session. Although no real hack has been performed against the shopping site, XSS has still exploited a scripting weakness in the page to snare a user and take command of his session. A trick which often is used to make malicious URLs less obvious is to have the XSS part of the URL encoded in HEX (or other encoding methods). This will look harmless to the user who recognizes the URL he is familiar with, and simply disregards and following ‘tricked’ code which would be encoded and therefore inconspicuous.

2. Site owners are always confident, but so are hackers!

Without going into complicated technical details, one must be aware of the various cases which have shown that XSS can have serious consequences when exploited on a vulnerable web application. Many site owners dismiss XSS on the grounds that it cannot be used to steal sensitive data from a back-end database. This is a common mistake because the consequences of XSS against a web application and its customers have been proven to be very serious, both in terms of application functionality and business operation. An online business project cannot afford to lose the trust of its present and future customers simply because nobody has ever stepped forward to prove that their site is really vulnerable to XSS exploits. Ironically, there are stories of site owners who have boldly claimed that XSS is not really a high-risk exploit. This has often resulted in a public challenge which hackers are always itching to accept, with the site owner having to later deal with a defaced application and public embarrassment.

3. The repercussions of XSS

Analysis of different cases which detail XSS exploits teaches us how the constantly changing web technology is nowhere close to making applications more secure. A thorough web search will reveal many stories of large-scale corporation web sites being hacked through XSS exploits, and the reports of such cases always show the same recurring consequences as being of the severe kind.

Exploited XSS is commonly used to achieve the following malicious results:

* Identity theft
* Accessing sensitive or restricted information
* Gaining free access to otherwise paid for content
* Spying on user’s web browsing habits
* Altering browser functionality
* Public defamation of an individual or corporation
* Web application defacement
* Denial of Service attacks

Any site owner with a healthy level of integrity would agree that none of the above can really be considered us frivolous or unimportant impacts on a vulnerable site. Security flaws in high-profile web sites have allowed hackers to obtain credit card details and user information which allowed them to perform transactions in their name. Legitimate users have been frequently tricked into clicking a link which redirects them to a malicious but legitimate-looking page which in turn captures all their details and sends them straight to the hacker. This example might not sound as bad as hacking into a corporate database; however it takes no effort to cause site visitors or customers to lose their trust in the application’s security which in turn can result in liability and loss of business.

4. Why wait to be hacked?

The observation which can be made when new stories of the latest hacks are published is that the sites which belong to the large brands and corporations are hacked in exactly the same way as those sites owned by businesses on a much smaller budget. This clearly shows how lack of security is not a matter of resources, but it is directly dependant on the lack of awareness among businesses of all size. Statistically, 42% of web applications which request security audits are vulnerable to XSS, which is clearly the most recurring high-risk exploit among all the applications tested. The effort to raise awareness about how easy it is for an expert hacker to exploit a vulnerable application does not seem to be going too far. It is still very common to see the “We’ll see when I get hacked” mentality still lingering among site owners who finally risk losing a lot of money and also the trust of their customers. Anybody with the interest to research this matter will see how even individuals claiming to be security experts feel comfortable to state that XSS is over-rated and cannot really be used to achieve serious results on a web application. However further research will also prove that statistical figures speak for themselves, and those same statistics keep growing at a rate which will eventually overcast the claims of those incredulous “experts”.

Web Application Security

While the adoption of Web-based technologies for conducting e-business has enabled organizations to connect seamlessly with suppliers, customers and other stakeholders, it has also exposed a multitude of previously unknown security risks.

If web application security is not taken care of, meaning that web application vulnerability is allowed to happen, then your entire database of sensitive information is at serious risk.

Some hackers, for example, will take advantage of web application vulnerabilities and may maliciously inject code within vulnerable web applications to trick users and redirect them towards phisphing sites. This technique is called Cross-Site Scripting or XSS and may be used even when the web servers and database engine contain no vulnerabilities themselves.

Recent research shows that 75% of cyber attacks are done at web application level. Hence ensuring web application security is crucial.


Click on Image to Enlarge

  • Websites and related web applications must be available 24 hours a day, 7 days a week to provide the required service to customers, employees, suppliers and other stakeholders
  • Firewalls and SSL provide no web application security nor protection against web application hacking, simply because access to the website has to be made public – ports 80 and 443 must remain open to allow the web application retrieve, deliver and update the data residing within the database servers
  • Web applications often have direct access to backend data such as customer databases and, hence, control valuable data and are much more difficult to secure
  • Most web applications are custom-made and, therefore, involve a lesser degree of testing than off-the-shelf software. Consequently, custom applications are more susceptible to attack