Security issue in the output files

[shay_cohen007]

hi, i created project in Captivate 8 that include text entry box and and click box.

after i published the project, i sent the output file to scan and i got 2 security issues:

1. Client Potential XSS

for example:

Method function at line 20731 of /gdolim/assets/js/CPM.js gets user input for the text element. This element’s

value then flows through the code without being properly sanitized or validated and is eventually displayed to

the user in method function at line 20731 of /gdolim/assets/js/CPM.js. This may enable a Cross-Site-Scripting

attack.

2. Client Potential Code Injection

for example:

Method "utf-8"),d.b||d.c?d.c? at line 36 of /gdolim/assets/js/CPXHRLoader.js gets a client-side controlled

data for the text element. This element’s value is used in client-side code without being properly sanitized or

validated and is eventually integrated into the HTML code in "utf-8"),d.b||d.c?d.c? at line 36 of

/gdolim/assets/js/CPXHRLoader.js.

Do I have any way to correct the problem? 

[RodWard]

How is this content going to be accessed by the learner?  Will it be from an LMS on a corporate network behind a firewall where the learner is required to be logged in?

[shay_cohen007]

i'm going to upload the project to my company website and the learner will get url to the project (not LMS).

before we upload any file to our server we scan it check if there is any security issue.

[RodWard · Accepted solution]

It's technically possible for a nefarious e-learning user could potentially use the opportunity afforded by entering text into a TEB to enter malicious code. However, this is not a very common situation.  (I've never heard of it happening with any of my clients.)

While Captivate does allow validation of TEB values, this is done by setting up possible correct answers.  But that's not going to be a viable solution when you don't know in advance what the person's name might be. It also doesn't provide any default way to have the Text Entry Box variable value "sanitized" to ensure that malicious code is not pasted into the TEB instead of a valid user name.  In order to do that you would need to have a JavaScript programmer create some code that tests the entered text string for patterns and characters that are known to be used by hackers.

Do be quite honest, I think you are going to find that almost any JavaScript used in e-learning content could potentially be hacked under the right circumstances.  JavaScript is not really inherently any more secure than ActionScript (the coding language underpinning SWF).  It's one of the unpleasant facts that sort of got ignored by organisations in the lemming rush to get rid of Flash and SWF.

[shay_cohen007]

Thanks for the full answer.