|
Thank you all for the great feedback. Your responses speak to the heart of some important security issues that are addressed at design-time based on application requirements.
The app's architecture uses nonces (encrypted, non-sequential rotating keys) that are validated upon every request using https, so interacting with the system from outside the app is quite useless (Not discussing DOS-type attacks here...). Multiple, sequential invalid requests summarily terminate the session and suspend the IP address (or the user's proxy address) for a limited time.
Within the app all db operations are executed via stored procedures, and embedded SELECT statements are not possible, so SQL injections are quite unlikely.
Speaking of the client layer, if JavaScript is disabled then the app will not instantiate (including a <NOSCRIPT> message), and app interaction is not possible since AJAX, the sole app-interaction method, is thus disabled.
Client-side, the app may be compared to an application that publishes poems. A user types a poem into a textarea and submits it. Upon submission, a js AJAX call retrieves a binary unique ID from the db (transformed into base64), then embeds it into an XML tag which contains the submitted poem in addition to some metadata such as the title, formatting instructions and other data. The db stores the xml tag in a simple table with about five fields (binary id, date created, last accessed, xml tag containing the poem, userId who owns the poem).
The xml tag is retrieved in its entirety from the db, and is only processed on the browser (understand now why I need to maintain the XML's angle brackets while HTML-encoding those that are in the tag's value). In view mode the xml tag is available to public and is simply parsed by the browser and it's poem is displayed via xsl transformation and/or CSS. In edit mode the tag is parsed by js and its content embedded into INPUTs and TEXTAREAs.
Regarding security in such an application, I am concerned with malicious scripts that interfere with usability (and certainly securtiy) while in view mode, and less concerned with usability in edit mode (let the user who is screwing around go scr*w himself lol).
...which brings us around to encoding angle brackets and quotes as entity references in order to protect viewers. If I appear to have overlooked anything then I would thank you for pointing it out.
...also, this bring us back to a discussion on the most efficient and effective way to encode/decode the entity references. Native js functions are executed in js' native low-level language, and thus execute more efficiently than interpreted functions that parse text. If a native js function can get this done then I would like to know about it, otherwise, what is the best option for performance?
|