- Email: [email protected]
Cross-site scripting – an alternative view
DATA ENCRYPTION look-out for an unattended laptop, information is widely available. Organizations need to secure every facet of the information they hold so dear – no matter whether it is at rest or in motion.
About the author Andy Solterbeck is VP & general manager, Commercial Enterprise Business
Unit, SafeNet. He relocated to the United States from Australia to join SafeNet in July 2005 as the general manager, Data Protection Business Unit, a newly formed position within the company. In July 2006, SafeNet combined the Borderless product line with the High Speed product line into a new Commercial Enterprise Business Unit
of which he was named Vice President and General Manager. In 2000, Mr. Solterbeck helped establish a company known as Axis8, where he later served as the company’s Chief Technical Officer. The organization was developed to leverage new communications technology to allow organizations to better interact with their customers.
CROSS-SITE SCRIPTING
Cross-site scripting – an alternative view Richard Braganza, consultant, Siemens Insight Consulting With fresh interest in techniques for combating cross-site scripting (XSS) attacks, this article explores ways to help future proof websites, and the applications that they run, from XSS attacks. Ideas are put forward on how to stop XSS from allowing attackers to escalate privilege and gain access to restricted resources. Cross-site scripting (XSS – or CSS – for short) is yet another form of computerised attack over the Internet and XSS attacks are usually aimed at applications running on web servers, i.e. a website with forms to be filled in. The attack is different from most other forms of attack because it uses a vulnerable website application to allow a malicious person to attack other users. In other words, there are at least three parties in a XSS attack: • The malicious person or attacker • The vulnerable website application • Another user of the website – the victim or victims.
Timeline of an XSS attack The attacker fills in the forms on the vulnerable website. The website server processes the data in the forms. Vulnerable websites generally make two mistakes when dealing with user supplied filled in forms.
September 2006
• The first error is to allow characters that were not to be expected for that form. For example, a form asking the user to fill in a postcode for a certain country should only expect to receive alphabetic, numeric and space characters in the postcode. Other characters received for this field need to be removed. • The second error is to store and subsequently allow the display of the user supplied data without removing unexpected characters and not to encode the output for the relevant display – thereby displaying some or all of the attacker supplied form details to other users. These two mistakes allow the end user to see exactly what the attacker entered into their forms. Normally the entered material is seen as text and is not a cause for concern (other than it may not be very politically correct). But with careful editing, the attacker can put together material that appears
normal, yet also contains XSS content. Browsers see XSS content and execute it. The end user has limited control over what was run and may not even be aware something was run on his browser by the attacker. In summary, a victim, simply viewing the website that is vulnerable to XSS, allows attackersupplied XSS content to be misinterpreted and run by the victim’s browser.
“I’m alright Jack?” Some think “XSS attacks the user and not the server,” leaving it intact. The attacker has used the website to deliver their content to the other user(s) of the website – the victim(s). XSS attack content will typically cause the victim’s browser to run something. Note, the browser is running on the victim’s PC. So, first thoughts are: “The victim’s PC has been targeted.” Websites use cookies to keep track of each user. For example, buying something online is a multi-stage process. The shopper has to: 1. 2. 3. 4.
Select the items they want Confirm they wish to buy Agree postage and discounts Enter purchasing details – like credit card information 5. Enter delivery information 6. Optionally, track their order. A website may have many of these transactions happening at the same time. Each transaction stage will be different for each shopper. The web server sends each shopper a unique cookie
Network Security
17
CROSS-SITE SCRIPTING that allows the web server to know where in the transaction the shopper is. i.e. the cookie identifies the shopper. The cookie needs to be protected from theft/impersonation. The attacker can also get cookie information from the victim by using XSS to send the victim’s cookie content to the attacker (or a website he controls) using normal web page request methods. Thus allowing the hijacking of ‘shopper sessions’ – the attacker steals the identity (cookie) of the victim and gains all their rights and access on the vulnerable website. In this case, they can get the user to buy goods for the attacker.
Wrong again Some might also think: “The shop’s website may be vulnerable to XSS, but they were not affected – only the end users.” Wrong again. What would happen if the attacker used XSS, to get another user, to add a new administrator to the website? Under normal circumstances, most unauthenticated users would have similar website privileges to the attacker. The ‘add new administrator’ would not be possible. Nothing bad would happen to the website when most other users viewed (ran) the XSS. But, if the other user was an administrator... hey presto, an attacker would create a new administrator account – or rather has got the victim user to create it, simply by having the user view your website in their browser and running the attacker’s XSS code. If the website logs are examined, who do you think will get the blame? – The victim, of course – they did it – it’s there in the logs! An attacker could use XSS to create content on your website that offended other users or otherwise damaged the public image and reputation of your web service.
Reliant on browser’s code XSS relies on victims’ browsers running code. Web pages consist mainly of HTML, which is simply structural and organises information on the web page; 18
Network Security
< %3C < < < < < < < < < < < <
< < < < < < < < < < < < < <
< < < < < < < < < < < < < <
< < < < < < < < < < < < \x3c \x3C
< < < < < < < < < < < < \u003c \u003C
Figure 1: Character sequences
there is very little chance any code can be run in HTML-only web pages. But web pages can also consist of scripts, style sheets, animations or plugins etc. These provide the mechanism to allow code to be run by a browser. A typical example is JavaScript which is designed to run on the user’s PC when a user visits a website. Normally, the script or other language is used to enhance the user’s experience of a website and is controlled by the website designer. In an XSS attack, the attacker can add a JavaScript script to a web page, even one that was HTML-only, if the website allows it. The script would do what the attacker wanted, subject to the script language limitations.
When is a ‘<’ symbol not a ‘<’ symbol? XSS is not limited to JavaScript. Checking user supplied data against a list of ‘bad’ characters is not feasible. In theory, any set of characters can be used in XSS if there is a browser out there that is running an exotic plug-in or application. Each character can also be replaced by sequences of characters that the browser will interpret as the same character. Any of the character sequences (see Figure 1 – the list is not definitive and is constantly growing) can produce a ‘<’ under the right conditions. It just depends on the web page encoding character set, user’s browser and browser version. The ‘<’ is important as it is
one of the characters used to delineate an HTML command. The ‘>’ character being the other one. In HTML the web page text is interspersed with HMTL tags/commands that tell the user’s browser to do something to the text.
For example: Website Name
when viewed by a browser on a web page will display the words ‘Website Name’ in bold.HTML can also call or rather embed other languages or scripts, causing the browser to run them when the web page is viewed. Browsers can run many different ‘handlers’. The handlers handle each type of language used on a web page – each one of them needs to be checked that the website is not vulnerable to XSS through that handler. On the plus side, it normally takes a few attempts for an attacker to perfect their XSS attack as the code that will work successfully normally needs substantial fine tuning. Just how much do you trust your browser – or rather how much can you rely on a user’s browser to protect them from your website? The simple answer is you cannot rely on the user’s browser. The browser is not in your control, no matter how much JavaScript you employ to enforce which browsers you want accessing your website. The user’s browser will have plugins, will be upgraded, will not be the
September 2006
CROSS-SITE SCRIPTING latest version, will have vulnerabilities and worse, will have widely available exploits invented in the future.
How to design a website (Part 1 – Best practice) The following are some ideas taken from various security forums that have discussed XSS attacks and how to prevent them.
Rule 1 In web forms, check all user supplied material uses only allowed characters. Create a white list of allowed characters for each web form field and remove all characters supplied by the user that are not in the white list.
Rule 2 Encode all user supplied data that is displayed on your website using the appropriate encoding. For example, if the user supplied data is used to create a hyperlink on the website, then ensure the hyperlink is URL encoded. Similarly, if the user supplied data is simply displayed on the website, ensure it is HTML encoded. Rules 1 and 2 are known as sanitising user input and output respectively.
Rule 4 Use different domain names for different levels of access. For example, a website administrator must not use the same domain for the website as a normal unauthenticated user. In fact, the administrator must have no rights on the normal unauthenticated user’s version of the website. This assumes an attacker will not know the names of other websites used for the more privileged users . This is security by obscurity, and an attacker with the requisite knowledge could make use of it. However, you have added another security layer to help protect your web site.
“With careful editing, the attacker can put together material that appears normal, yet also contains XSS content.” Of course, the extra complexity in managing multiple websites needs to be factored in against the increase in security. It comes down to what is the price of having a website compromised.
Rule 5 Rule 3
This rule is actually a two-part rule:
Application firewalls have been advocated – but these are simply dedicated 3rd party supplied versions of rules 1 and 2. Consideration needs to be given to whether the application firewall is updated regularly. The XSS field is a highly evolving field. Regular updates to the application firewall would be essential.
• Limit access to the administration section of the website by IP address • Do not allow access to the normal live website domain from these IPs. Only allow access to the administration section/domain of the site.
How to design a website (Part 2 – A new approach) I would also like to propose some new additional approaches to deal with XSS; this will aid the website designer to future proof their website from future advances in XSS technology.
September 2006
In other words an administrator can only see the admin pages and not what a normal user can see. A normal user cannot see the admin pages. If this is done for each privilege level and combined with rule 4, then the risk of one user escalating their privilege and performing tasks that they should not is severely reduced. Website management complexity will increase as the downside.
Again, a knowledgeable attacker could still implant the XSS trojan code by spoofing their IP address. They do not care that the resultant web pages are not sent to them. And again, this is security by obscurity. But it is yet another layer of defence that the attacker has to deal with. An attacker, trying to work all this out, will show up in the logs for each website facilitating investigation, containment and control of the attack before the attack is perfected.
Rule 6 Create a honey pot version of the unauthenticated or other lower privilege level versions of the website in a test network – only accessible from the administrator’s PCs. Ensure the administrator’s hosts file points the administrator away from the real unauthenticated user version of the website, but instead points the administrator to the honey pot version. The idea here is if the administrator inadvertently becomes the victim of XSS targeting the normal user site, it will work, but not on the live site, only on the dummy honey pot site. In other words the administrator will see the attack and the symptoms, whereas the attacker will not. The administrator can then go on and do some investigation into the XSS attack and take remedial action before the attack is perfected.
Rule 7 Monitor the honey pot for access. Remember all access is because an administrator is accessing the live website – which we disallowed in rule 4. One of three types of access will have been recorded: • Live user ‘finger trouble’ – mis-typing a word and somehow creating some XSS code and posting that code to the website – highly unlikely given the complexity of XSS code • A genuine XSS attack. Analyse it and see what you have missed sanitising in the website; track down the
Network Security
19
NEWS
IBM brings ISS into the family
I
nternet Security Systems, a security products and services provider that pre-emptively protects enterprise organizations against Internet threats, has been purchased by IBM in a cash deal valued at $1.3bn.
The deal is expected to be finalised by the end of 2006, subject to approval by regulators. The purchase considerably increases the IT services aspect of IBM’s portfolio, and especially in the area of managed security services, one of ISS’s strengths, and where it regularly competed against the likes of Symantec. The businesses have been working closely together since 1999 and ISS will retain some autonomy while under the IBM umbrella: • ISS operations will be established as a business unit within IBM’s Infrastructure Management Services unit, part of IBM Global Technology Services; • ISS software technology will be integrated with Tivoli’s IT service management portfolio, which includes software for Identity Management,
Access Management, Service Oriented Architecture (SOA) security and Security Information Management; • ISS managed security services portfolio will be marketed and sold through IBM’s and ISS worldwide sales channels and business partners. “Companies recognize that rapidly evolving security threats and complex regulatory requirements have turned security into a mission-critical priority,” said Val Rahmani, General Manager, Infrastructure Management Services, IBM Global Services. “ISS is a strategic and valuable addition to IBM’s portfolio of technology and services. This acquisition will help IBM to provide companies with access to trained experts and leading-edge processes and technology to evaluate and protect against threats and enforce security policies.” IBM currently has over 3,500 professionals delivering consulting, implementation and out-tasking security services to thousands of organizations all over the world. ISS security products are currently used by 11,000 customers worldwide including 17 of the world’s largest banks and 15 of the largest governments
EVENTS CALENDAR 18-20 September 2006 ISACA Network Security Conference USA Location: Las Vegas, USA Website: www.isaca.org
19-21 September 2006 Infosecurity Scandinavia Location: Stockholm, Sweden Website: www.infosecworld.com
11-13 September 2006 International Conference for Internet Technology and Secured Transactions (ICITST2006) Location: London, UK Website: www.icitst.org
2-4 October 2006 IFIP International Conference on Network and Parallel Computing Location: Tokyo, Japan Website: www.npcconf.org
5-6 October 2006 Black Hat Japan 2006 CROSS-SITE SCRIPTING
Location: Tokyo, Japan Website: www.blackhat.com
...continued from page 19
perpetrator. Take remedial action on all websites you have control of • Accidental administrator access – genuinely tried to access the live website from an administrator’s PC.
Security by layers – Summary Do not rely on sanitising user input and output. Instead add further layers of security by ensuring website users and administrators use different ‘views’ or websites. You will decrease the chance of the website being vulnerable to XSS. Future advances in XSS are likely to have less effect on your website and its users. Of course user peer attacks are still possible – rules 1 to 3 are the defences here.
20
Network Security
Rules 4 to 7 are there to further decrease the chances of successful XSS attacks from attackers trying to escalate privilege.
11-13 October 2006
References
International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2006)
A. Klein, “Cross Site Scripting Explained.” Sanctum White Paper, May 2002. http://crypto.stanford.edu/cs155/CSS.pdf
Location: London, UK Website: www.icmu.org/icmu2006/index. html
About the author Richard Braganza is a consultant with Siemens Insight Consulting in the Technical Assurance Application Test Team. He has spent more than 20 years in software development and security, covering several areas ranging from miniature realtime systems to large enterprise fault tolerant high-availability systems.
23-25 October 2006 RSA Conference Europe 2006 Location: Nice, France Website: www.rsaconference.com
24-25 October 2006 Infosecurity USA Location: New York, USA Website: www.infosecworld.com
September 2006
About the author Andy Solterbeck is VP & general manager, Commercial Enterprise Business
Unit, SafeNet. He relocated to the United States from Australia to join SafeNet in July 2005 as the general manager, Data Protection Business Unit, a newly formed position within the company. In July 2006, SafeNet combined the Borderless product line with the High Speed product line into a new Commercial Enterprise Business Unit
of which he was named Vice President and General Manager. In 2000, Mr. Solterbeck helped establish a company known as Axis8, where he later served as the company’s Chief Technical Officer. The organization was developed to leverage new communications technology to allow organizations to better interact with their customers.
CROSS-SITE SCRIPTING
Cross-site scripting – an alternative view Richard Braganza, consultant, Siemens Insight Consulting With fresh interest in techniques for combating cross-site scripting (XSS) attacks, this article explores ways to help future proof websites, and the applications that they run, from XSS attacks. Ideas are put forward on how to stop XSS from allowing attackers to escalate privilege and gain access to restricted resources. Cross-site scripting (XSS – or CSS – for short) is yet another form of computerised attack over the Internet and XSS attacks are usually aimed at applications running on web servers, i.e. a website with forms to be filled in. The attack is different from most other forms of attack because it uses a vulnerable website application to allow a malicious person to attack other users. In other words, there are at least three parties in a XSS attack: • The malicious person or attacker • The vulnerable website application • Another user of the website – the victim or victims.
Timeline of an XSS attack The attacker fills in the forms on the vulnerable website. The website server processes the data in the forms. Vulnerable websites generally make two mistakes when dealing with user supplied filled in forms.
September 2006
• The first error is to allow characters that were not to be expected for that form. For example, a form asking the user to fill in a postcode for a certain country should only expect to receive alphabetic, numeric and space characters in the postcode. Other characters received for this field need to be removed. • The second error is to store and subsequently allow the display of the user supplied data without removing unexpected characters and not to encode the output for the relevant display – thereby displaying some or all of the attacker supplied form details to other users. These two mistakes allow the end user to see exactly what the attacker entered into their forms. Normally the entered material is seen as text and is not a cause for concern (other than it may not be very politically correct). But with careful editing, the attacker can put together material that appears
normal, yet also contains XSS content. Browsers see XSS content and execute it. The end user has limited control over what was run and may not even be aware something was run on his browser by the attacker. In summary, a victim, simply viewing the website that is vulnerable to XSS, allows attackersupplied XSS content to be misinterpreted and run by the victim’s browser.
“I’m alright Jack?” Some think “XSS attacks the user and not the server,” leaving it intact. The attacker has used the website to deliver their content to the other user(s) of the website – the victim(s). XSS attack content will typically cause the victim’s browser to run something. Note, the browser is running on the victim’s PC. So, first thoughts are: “The victim’s PC has been targeted.” Websites use cookies to keep track of each user. For example, buying something online is a multi-stage process. The shopper has to: 1. 2. 3. 4.
Select the items they want Confirm they wish to buy Agree postage and discounts Enter purchasing details – like credit card information 5. Enter delivery information 6. Optionally, track their order. A website may have many of these transactions happening at the same time. Each transaction stage will be different for each shopper. The web server sends each shopper a unique cookie
Network Security
17
CROSS-SITE SCRIPTING that allows the web server to know where in the transaction the shopper is. i.e. the cookie identifies the shopper. The cookie needs to be protected from theft/impersonation. The attacker can also get cookie information from the victim by using XSS to send the victim’s cookie content to the attacker (or a website he controls) using normal web page request methods. Thus allowing the hijacking of ‘shopper sessions’ – the attacker steals the identity (cookie) of the victim and gains all their rights and access on the vulnerable website. In this case, they can get the user to buy goods for the attacker.
Wrong again Some might also think: “The shop’s website may be vulnerable to XSS, but they were not affected – only the end users.” Wrong again. What would happen if the attacker used XSS, to get another user, to add a new administrator to the website? Under normal circumstances, most unauthenticated users would have similar website privileges to the attacker. The ‘add new administrator’ would not be possible. Nothing bad would happen to the website when most other users viewed (ran) the XSS. But, if the other user was an administrator... hey presto, an attacker would create a new administrator account – or rather has got the victim user to create it, simply by having the user view your website in their browser and running the attacker’s XSS code. If the website logs are examined, who do you think will get the blame? – The victim, of course – they did it – it’s there in the logs! An attacker could use XSS to create content on your website that offended other users or otherwise damaged the public image and reputation of your web service.
Reliant on browser’s code XSS relies on victims’ browsers running code. Web pages consist mainly of HTML, which is simply structural and organises information on the web page; 18
Network Security
< %3C < < < < < < < < < < < <
< < < < < < < < < < < < < <
< < < < < < < < < < < < < <
< < < < < < < < < < < < \x3c \x3C
< < < < < < < < < < < < \u003c \u003C
Figure 1: Character sequences
there is very little chance any code can be run in HTML-only web pages. But web pages can also consist of scripts, style sheets, animations or plugins etc. These provide the mechanism to allow code to be run by a browser. A typical example is JavaScript which is designed to run on the user’s PC when a user visits a website. Normally, the script or other language is used to enhance the user’s experience of a website and is controlled by the website designer. In an XSS attack, the attacker can add a JavaScript script to a web page, even one that was HTML-only, if the website allows it. The script would do what the attacker wanted, subject to the script language limitations.
When is a ‘<’ symbol not a ‘<’ symbol? XSS is not limited to JavaScript. Checking user supplied data against a list of ‘bad’ characters is not feasible. In theory, any set of characters can be used in XSS if there is a browser out there that is running an exotic plug-in or application. Each character can also be replaced by sequences of characters that the browser will interpret as the same character. Any of the character sequences (see Figure 1 – the list is not definitive and is constantly growing) can produce a ‘<’ under the right conditions. It just depends on the web page encoding character set, user’s browser and browser version. The ‘<’ is important as it is
one of the characters used to delineate an HTML command. The ‘>’ character being the other one. In HTML the web page text is interspersed with HMTL tags/commands that tell the user’s browser to do something to the text.
For example: Website Name
when viewed by a browser on a web page will display the words ‘Website Name’ in bold.HTML can also call or rather embed other languages or scripts, causing the browser to run them when the web page is viewed. Browsers can run many different ‘handlers’. The handlers handle each type of language used on a web page – each one of them needs to be checked that the website is not vulnerable to XSS through that handler. On the plus side, it normally takes a few attempts for an attacker to perfect their XSS attack as the code that will work successfully normally needs substantial fine tuning. Just how much do you trust your browser – or rather how much can you rely on a user’s browser to protect them from your website? The simple answer is you cannot rely on the user’s browser. The browser is not in your control, no matter how much JavaScript you employ to enforce which browsers you want accessing your website. The user’s browser will have plugins, will be upgraded, will not be the
September 2006
CROSS-SITE SCRIPTING latest version, will have vulnerabilities and worse, will have widely available exploits invented in the future.
How to design a website (Part 1 – Best practice) The following are some ideas taken from various security forums that have discussed XSS attacks and how to prevent them.
Rule 1 In web forms, check all user supplied material uses only allowed characters. Create a white list of allowed characters for each web form field and remove all characters supplied by the user that are not in the white list.
Rule 2 Encode all user supplied data that is displayed on your website using the appropriate encoding. For example, if the user supplied data is used to create a hyperlink on the website, then ensure the hyperlink is URL encoded. Similarly, if the user supplied data is simply displayed on the website, ensure it is HTML encoded. Rules 1 and 2 are known as sanitising user input and output respectively.
Rule 4 Use different domain names for different levels of access. For example, a website administrator must not use the same domain for the website as a normal unauthenticated user. In fact, the administrator must have no rights on the normal unauthenticated user’s version of the website. This assumes an attacker will not know the names of other websites used for the more privileged users . This is security by obscurity, and an attacker with the requisite knowledge could make use of it. However, you have added another security layer to help protect your web site.
“With careful editing, the attacker can put together material that appears normal, yet also contains XSS content.” Of course, the extra complexity in managing multiple websites needs to be factored in against the increase in security. It comes down to what is the price of having a website compromised.
Rule 5 Rule 3
This rule is actually a two-part rule:
Application firewalls have been advocated – but these are simply dedicated 3rd party supplied versions of rules 1 and 2. Consideration needs to be given to whether the application firewall is updated regularly. The XSS field is a highly evolving field. Regular updates to the application firewall would be essential.
• Limit access to the administration section of the website by IP address • Do not allow access to the normal live website domain from these IPs. Only allow access to the administration section/domain of the site.
How to design a website (Part 2 – A new approach) I would also like to propose some new additional approaches to deal with XSS; this will aid the website designer to future proof their website from future advances in XSS technology.
September 2006
In other words an administrator can only see the admin pages and not what a normal user can see. A normal user cannot see the admin pages. If this is done for each privilege level and combined with rule 4, then the risk of one user escalating their privilege and performing tasks that they should not is severely reduced. Website management complexity will increase as the downside.
Again, a knowledgeable attacker could still implant the XSS trojan code by spoofing their IP address. They do not care that the resultant web pages are not sent to them. And again, this is security by obscurity. But it is yet another layer of defence that the attacker has to deal with. An attacker, trying to work all this out, will show up in the logs for each website facilitating investigation, containment and control of the attack before the attack is perfected.
Rule 6 Create a honey pot version of the unauthenticated or other lower privilege level versions of the website in a test network – only accessible from the administrator’s PCs. Ensure the administrator’s hosts file points the administrator away from the real unauthenticated user version of the website, but instead points the administrator to the honey pot version. The idea here is if the administrator inadvertently becomes the victim of XSS targeting the normal user site, it will work, but not on the live site, only on the dummy honey pot site. In other words the administrator will see the attack and the symptoms, whereas the attacker will not. The administrator can then go on and do some investigation into the XSS attack and take remedial action before the attack is perfected.
Rule 7 Monitor the honey pot for access. Remember all access is because an administrator is accessing the live website – which we disallowed in rule 4. One of three types of access will have been recorded: • Live user ‘finger trouble’ – mis-typing a word and somehow creating some XSS code and posting that code to the website – highly unlikely given the complexity of XSS code • A genuine XSS attack. Analyse it and see what you have missed sanitising in the website; track down the
Network Security
19
NEWS
IBM brings ISS into the family
I
nternet Security Systems, a security products and services provider that pre-emptively protects enterprise organizations against Internet threats, has been purchased by IBM in a cash deal valued at $1.3bn.
The deal is expected to be finalised by the end of 2006, subject to approval by regulators. The purchase considerably increases the IT services aspect of IBM’s portfolio, and especially in the area of managed security services, one of ISS’s strengths, and where it regularly competed against the likes of Symantec. The businesses have been working closely together since 1999 and ISS will retain some autonomy while under the IBM umbrella: • ISS operations will be established as a business unit within IBM’s Infrastructure Management Services unit, part of IBM Global Technology Services; • ISS software technology will be integrated with Tivoli’s IT service management portfolio, which includes software for Identity Management,
Access Management, Service Oriented Architecture (SOA) security and Security Information Management; • ISS managed security services portfolio will be marketed and sold through IBM’s and ISS worldwide sales channels and business partners. “Companies recognize that rapidly evolving security threats and complex regulatory requirements have turned security into a mission-critical priority,” said Val Rahmani, General Manager, Infrastructure Management Services, IBM Global Services. “ISS is a strategic and valuable addition to IBM’s portfolio of technology and services. This acquisition will help IBM to provide companies with access to trained experts and leading-edge processes and technology to evaluate and protect against threats and enforce security policies.” IBM currently has over 3,500 professionals delivering consulting, implementation and out-tasking security services to thousands of organizations all over the world. ISS security products are currently used by 11,000 customers worldwide including 17 of the world’s largest banks and 15 of the largest governments
EVENTS CALENDAR 18-20 September 2006 ISACA Network Security Conference USA Location: Las Vegas, USA Website: www.isaca.org
19-21 September 2006 Infosecurity Scandinavia Location: Stockholm, Sweden Website: www.infosecworld.com
11-13 September 2006 International Conference for Internet Technology and Secured Transactions (ICITST2006) Location: London, UK Website: www.icitst.org
2-4 October 2006 IFIP International Conference on Network and Parallel Computing Location: Tokyo, Japan Website: www.npcconf.org
5-6 October 2006 Black Hat Japan 2006 CROSS-SITE SCRIPTING
Location: Tokyo, Japan Website: www.blackhat.com
...continued from page 19
perpetrator. Take remedial action on all websites you have control of • Accidental administrator access – genuinely tried to access the live website from an administrator’s PC.
Security by layers – Summary Do not rely on sanitising user input and output. Instead add further layers of security by ensuring website users and administrators use different ‘views’ or websites. You will decrease the chance of the website being vulnerable to XSS. Future advances in XSS are likely to have less effect on your website and its users. Of course user peer attacks are still possible – rules 1 to 3 are the defences here.
20
Network Security
Rules 4 to 7 are there to further decrease the chances of successful XSS attacks from attackers trying to escalate privilege.
11-13 October 2006
References
International Conference on Mobile Computing and Ubiquitous Networking (ICMU 2006)
A. Klein, “Cross Site Scripting Explained.” Sanctum White Paper, May 2002. http://crypto.stanford.edu/cs155/CSS.pdf
Location: London, UK Website: www.icmu.org/icmu2006/index. html
About the author Richard Braganza is a consultant with Siemens Insight Consulting in the Technical Assurance Application Test Team. He has spent more than 20 years in software development and security, covering several areas ranging from miniature realtime systems to large enterprise fault tolerant high-availability systems.
23-25 October 2006 RSA Conference Europe 2006 Location: Nice, France Website: www.rsaconference.com
24-25 October 2006 Infosecurity USA Location: New York, USA Website: www.infosecworld.com
September 2006