Skip to main content
WolfShade
WolfShade
Legend
November 23, 2016
Question

XSS - I'm overthinking this..

  • November 23, 2016
  • 2 replies
  • 554 views

Hello, all,

I'm overly concerned about XSS attempts on my sites.  I cannot seem to find a decent solution.

I know that as far as using URL parameters on server-side processing, you should use canonicalize() to reduce encoded script to what a potential bad actor intended to run on the server, and sanitize from there.  Apparently, whitelisting is a very effective method.  But, what about when whitelisting isn't an option (like, for example, input into a database, or used as a conditional for database processing)?

Also, what about client-side effects?  I've seen where URL parameters can be used to inject JavaScript code into a page.  Now, I know that EncodeForURL() and others should be used, but how can one manipulate the URL so that XSS would be rendered useless??  Without using a redirect like CFLOCATION??

V/r,

^_^

PS:  It's the day before Thanksgiving Day, in the USA, so I won't be on much between now and Monday.  Happy Thanksgiving Day to all American users!

    This topic has been closed for replies.

    2 replies

    A
    abrocket1957
    Participant
    December 12, 2016

    My team has been working on tightening up XSS vulnerabilities on our old code.

    One of the things you said really bothered me: " like, for example, input into a database, or used as a conditional for database processing"

    I really, really hope you are not just taking URL vars and using them in your queries. THAT is an XSS problem.

    So, just a few tips we've put together during our project

    1. Don't use URL variables unless you have to (framework?)

    2. move URL vars to client (presumes client vars are db stored on server side - Cookies can be hacked).

    3. Use <cfsqlqueryparam ... > in all queries

    4. You can whitelist url vars, but you also have to validate accepted values. (e.g., "id" must be integer, "name" is alpha, with a max length ...)

    5. No hidden form values (these can be spoofed)

    6. Use CreateUUID() for unique identifiers and validate always

    7. NEVER EVER display user input back to the screen.

    just a few off the top of my head.

    BKBK
    Community Expert
    BKBKCommunity Expert
    Community Expert
    November 29, 2016

    @Wolfshade, you can never overthink security risks. I share your concerns.

    Infact I, too, spent some time last year, looking into this very issue for our own sites. I found, a bit to my dismay, that the attacker could strike from many fronts. It means you have to defend on many fronts.

    I drew up a check-list. It contained, among others, url-encode, canonicalize, ScriptProtect, code to detect simultaneous logins, HTTPOnly cookies and Content Security Policy. When I was drawing up the list, I found these two sites useful

    Cross-site scripting - Wikipedia

    Cross-site Scripting (XSS) - OWASP

    WolfShade
    WolfShadeAuthor
    Legend
    November 30, 2016

    Thanks for the links, BKBK​.  I'll see if there's anything useful I can use.

    V/r,

    ^_^

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices