Hi all, I came across a security alert that basically embeds javascript in the display name of the From to initiate cross-site-scripting (XSS) attacks. Here is an example:
From: "<script>alert('hack')</script>""user" <sip:user at domain.com https://lists.grok.org.uk/mailman/listinfo/full-disclosure>;tag=002a000c
Grammatically , I don't see an issue with this. However, under the right circumstances this could get ugly. Do you see value in having openser take a proactive role to detect these and reject calls? Or is this outside the scope of what a proxy should be doing (leave it to the UA to sanitize) ?
Looking to get your thoughts- -will
At 18:13 17/10/2007, William Quan wrote:
Hi all, I came across a security alert that basically embeds javascript in the display name of the From to initiate cross-site-scripting (XSS) attacks. Here is an example:
From: "<script>alert('hack')</script>""user" <sip:user at domain.com https://lists.grok.org.uk/mailman/listinfo/full-disclosure>;tag=002a000c
Grammatically , I don't see an issue with this. However, under the right circumstances this could get ugly. Do you see value in having openser take a proactive role to detect these and reject calls? Or is this outside the scope of what a proxy should be doing (leave it to the UA to sanitize) ?
We have been thinking hard of this in the SER community. My 2 cents are that sanitizing in the proxy is of limited impact. The trouble is that it is not just JavaScript, it can be literally any application in any language, which is tunneled some crafted data through SIP. The SIP proxy can be tought to detect JavaScript but who knows what is going to come next. Thus I think that JAva-Script enabled apps should test SER-produced data for Java-script data, and XYZ-apps should test SER-produced data for XYZ-script data.
As an example, the latest serweb version, which uses JavaScript, is resistant against such JavaScript attacks.
-jiri
Looking to get your thoughts- -will
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
-- Jiri Kuthan http://iptel.org/~jiri/
William Quan wrote:
Hi all, I came across a security alert that basically embeds javascript in the display name of the From to initiate cross-site-scripting (XSS) attacks. Here is an example:
From: "<script>alert('hack')</script>""user" <sip:user at domain.com https://lists.grok.org.uk/mailman/listinfo/full-disclosure>;tag=002a000c
Grammatically , I don't see an issue with this. However, under the right circumstances this could get ugly. Do you see value in having openser take a proactive role to detect these and reject calls? Or is this outside the scope of what a proxy should be doing (leave it to the UA to sanitize) ?
I think it should be left to the UA. It would be very difficult to come up with good sanitizing rules, and they would get out of data very quickly. Maybe an openser sanitizer module that would download SIP attack signatures would make sense.
/Christian
Looking to get your thoughts- -will
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
I was thinking about this problem and I think that combining this module idea with the ones presented by Jiri could guide to an intermediary and more flexible one.
Any sanitization task would be processed by a dedicated module. This module could load as many 'sanitizations descriptions' as desired. Each 'sanitization description' could be a XML file (just to give an exemple) and would take care of an especific language or language family. It could describe signatures, or even include language syntax and semantics checks (who knows what is really necessary?). This way, changing/improving the descriptions with language specific sanitization knownledge would extended the protection without the need of logical changes on the proxy script.
For sure even if the idea is easy to understand it's implementation is not a trivial work. But is an idea... ;)
Edson
-----Original Message----- From: users-bounces@openser.org [mailto:users-bounces@openser.org] On Behalf Of Christian Schlatter Sent: quarta-feira, 17 de outubro de 2007 20:27 To: William Quan Cc: users@openser.org Subject: Re: [OpenSER-Users] sanitizing sip requests
William Quan wrote:
Hi all, I came across a security alert that basically embeds javascript in the display name of the From to initiate cross-site-scripting (XSS) attacks. Here is an example:
From: "<script>alert('hack')</script>""user" <sip:user at domain.com <https://lists.grok.org.uk/mailman/listinfo/full-
disclosure>>;tag=002a000c
Grammatically , I don't see an issue with this. However, under the right circumstances this could get ugly. Do you see value in having openser take a proactive role to detect these and reject calls? Or is this outside the scope of what a proxy should be doing (leave it to the UA to sanitize) ?
I think it should be left to the UA. It would be very difficult to come up with good sanitizing rules, and they would get out of data very quickly. Maybe an openser sanitizer module that would download SIP attack signatures would make sense.
/Christian
Looking to get your thoughts- -will
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
On Thursday 18 October 2007, Edson wrote:
I was thinking about this problem and I think that combining this module idea with the ones presented by Jiri could guide to an intermediary and more flexible one.
Any sanitization task would be processed by a dedicated module. This module could load as many 'sanitizations descriptions' as desired. Each 'sanitization description' could be a XML file (just to give an exemple) and would take care of an especific language or language family. It could describe signatures, or even include language syntax and semantics checks (who knows what is really necessary?). This way, changing/improving the descriptions with language specific sanitization knownledge would extended the protection without the need of logical changes on the proxy script.
For sure even if the idea is easy to understand it's implementation is not a trivial work. But is an idea... ;)
Perhaps it makes more sense to use an IDS for this job, which already has the infrastructure present to search in the traffic and match against arbitrary rules. It can alert or kill the connection if something against the policy is detected.
Cheers,
Henning
William Quan schrieb:
Hi all, I came across a security alert that basically embeds javascript in the display name of the From to initiate cross-site-scripting (XSS) attacks. Here is an example:
From: "<script>alert('hack')</script>""user" <sip:user at domain.com https://lists.grok.org.uk/mailman/listinfo/full-disclosure>;tag=002a000c
Thats a cool attack. I fear there will be more smart attacks in the next time.
klaus
Grammatically , I don't see an issue with this. However, under the right circumstances this could get ugly. Do you see value in having openser take a proactive role to detect these and reject calls? Or is this outside the scope of what a proxy should be doing (leave it to the UA to sanitize) ?
Looking to get your thoughts- -will
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
On 10/18/07 10:47, Klaus Darilion wrote:
William Quan schrieb:
Hi all, I came across a security alert that basically embeds javascript in the display name of the From to initiate cross-site-scripting (XSS) attacks. Here is an example:
From: "<script>alert('hack')</script>""user" <sip:user at domain.com https://lists.grok.org.uk/mailman/listinfo/full-disclosure>;tag=002a000c
Thats a cool attack. I fear there will be more smart attacks in the next time.
cooler and cooler. My opinion is that the client should take care. I do not see any reason why an application will interpret the display or user name. It should be printed as it is. Same we can say may happen with the email, when the text message will be interpreted, but not just displayed. Would be funny to get compile errors or code executed when someone just gives a snippet in a message.
AFAIK, unless is need for escape/unescape, those values should be taken literally. Of course, having something in openser to detect/prevent would be nice, but just as an add-on. Don't forget that some headers bring nightmare after changing them -- although, in such cases, the caller device won't care too much :)
Cheers, Daniel
klaus
Grammatically , I don't see an issue with this. However, under the right circumstances this could get ugly. Do you see value in having openser take a proactive role to detect these and reject calls? Or is this outside the scope of what a proxy should be doing (leave it to the UA to sanitize) ?
Looking to get your thoughts- -will
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Users mailing list Users@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
At 16:26 18/10/2007, Daniel-Constantin Mierla wrote:
On 10/18/07 10:47, Klaus Darilion wrote:
William Quan schrieb:
Hi all, I came across a security alert that basically embeds javascript in the display name of the From to initiate cross-site-scripting (XSS) attacks. Here is an example:
From: "<script>alert('hack')</script>""user" <sip:user at domain.com https://lists.grok.org.uk/mailman/listinfo/full-disclosure>;tag=002a000c
Thats a cool attack. I fear there will be more smart attacks in the next time.
cooler and cooler. My opinion is that the client should take care. I do not see any reason why an application will interpret the display or user name.
'cos your phone has a webpage with received calls.
It should be printed as it is. Same we can say may happen with the email, when the text message will be interpreted, but not just displayed. Would be funny to get compile errors or code executed when someone just gives a snippet in a message.
AFAIK, unless is need for escape/unescape, those values should be taken literally. Of course, having something in openser to detect/prevent would be nice, but just as an add-on. Don't forget that some headers bring nightmare after changing them -- although, in such cases, the caller device won't care too much :)
possibly nice-to-have, but wasted effort IMO, see the previous email. something generally app-unaware ('cos who knows what the actual app is) can't filter app, and attempts to do so always lag behind the attackers or break the apps.
-jiri
-- Jiri Kuthan http://iptel.org/~jiri/
-
Christian Schlatter -
Daniel-Constantin Mierla -
Edson -
Henning Westerholt -
Jiri Kuthan -
Klaus Darilion -
William Quan