dataesr/scientific-paragraphs-categorization huggingface dataset:
Each camera was associated with a spatial covariate (trail vs. under vegetation) to check if trap location affects the detection probability. Data analyses were performed using the SECR package  (Borchers and Efford 2008; Efford et al. 2009 ) in R 4. 0. 3. First, we estimated the mean maximum distance moved (MMDM) by the individuals between captures. Then, we implemented SECR models. The trap detector type « count » was chosen for the analysis, allowing more than one detection per animal. A habitat mask was used with a buffer width of 3,000 m around each camera-trap (determined with the SECR package; Efford 2021), but excluding the deep cliffs considered as inaccessible for feral cats. This resulted in a sampling area of 60. 55 km 2. We assumed that home ranges of feral cats were distributed following a homogeneous spatial Poisson process during the trapping period  (Efford 2004; Borchers and Efford 2008; Efford et al.
Cross-site Scripting (XSS) is one of the most common and impactful software vulnerabilities (ranked second in the CWE 's top 25 in 2021). Several approaches have focused on automatically detecting software vulnerabilities through machine learning models. To build a model, it is necessary to have a dataset of vulnerable and non-vulnerable examples and to represent the source code in a computer understandable way. In this work, we explore the impact of predicting XSS using representations based on single-tier and multi-tier languages. We built 144 models trained on Javascript-based multitier code -i. e. which includes server code and HTML, Javascript and CSS as client code -and 144 models trained on single-tier code, which include sever code and client-side code as text. Despite the lower precision, our results show a better recall with multitier languages than a single-tier language, implying an insignificant impact on XSS detectors based on deep learning.
js, a multitier language based on JavaScript and datasets for Hop. js classified as XSS secure or insecure (Section 3). • We propose a new XSS static analyzer for Hop. js based on deep learning and the PLP code representation technique (Section 4). • We evaluate models in two different datasets one including HTML/JavaScript/CSS as code in Hop. js and one including it as text in Node. js, using PLP as code representation for deep mode languages. Finally, we compare our results (Section 5). 2 Hop. js and Node. js Languages For our experiments we have chosen two languages to program web applications which are based on JavaScript: Hop. js  (Serrano and Prunet, 2016)  and Node. js (Node. js, 2021). Hop. js  (Serrano and Prunet, 2016 ) is a multitier language 3 based on the JavaScript language and it is the successor of one of the two first multitier languages that existed HOP  (Serrano, 2006).
Hop. js Database for XSS In this work, we compare the effect of detecting XSS vulnerabilities in a multi-tier language based JavaScript language and Node. js with deep learning models. With that goal in mind, we represent the source code using ASTs. AST structures are widely used in the pre-processing stages of programming languages to analyze code at different granularity such as declaration level  (Shar and Tan, 2013) , function level  (Lin et al. , 2018) , the intra-procedural level  (Li and Zhou, 2005)  and the file level  (Wang et al. , 2016; Dam et al. , 2017). To build deep learning models that detects XSS, having a large ground-truth database of secure and insecure source code is one of the major obstacles. Only a few works have constructed real-world datasets for evaluation. However, these datasets are generally small, providing insufficiently labelled vulnerability data  (Lin et al.
, 2019; Lin et al. , 2018) , offering synthetic samples that cannot be compiled  (Choi et al. , 2017; Sestili et al. , 2018)  or are not publicly available. Another challenge related to creating a large ground truth database is the need to label every sample of the real-world's datasets. As it stands, this is tedious work done by hand for most research work  (Shar and Tan, 2013; Lin et al. , 2018; Li and Zhou, 2005; Li et al. , 2018b). Additionally, we need comparable web applications to assess the influence of semantic knowledge transcribed via AST for stand-alone multi-tier and single-tier web applications. For all of these reasons, in this work, we build a synthetic database that could be used as a benchmark dataset. For comparing this dataset with Node. js, we use the Node. js generator created by previous work  (Maurel et al.
, 2021). Because supervised deep learning requires to label, in our case, as secure or insecure each sample of the database, our generator is based on the OWASP XSS cheatsheet series project  (OWASP, 2021). This project proposes a positive model of rules using output encoding or filtering to prevent XSS attacks. We present the implementation of the OWASP rules in Hop. js in Section 3. 2.
Rule #0 -Never Insert Untrusted Data Except in Allowed Locations OWASP recommends that developers never put untrusted data directly into five HTML contexts. We implement these contexts for our Hop. js dataset. First, developers could insert an unreliable user data value -contained in a variable untrustedVarin a HTML attribute name. In the following code, the variable untrustedVar is an attribute of a HTML <div> tag: 1 let divVar= '<div ' + untrustedVar + '= "a" />'; 2 bodyVar. appendChild ( divVar ); 3 return <html> ${ headVar } ${ bodyVar } </ html>; The following is an full percent-encoded URL exploit for the above vulnerable code: 1 %3 E %3 c %73%63%72%69%70%74%3 e %61%6 c %65%72%74%28%31%29%3 c 2 %2 f %73%63%72%69%70%74%3 e 3 // Decoded version 4 ><script>alert (1) < %2 fscript> Second, developers have the possibility to insert an untrusted user data value -contained in a untrustedVar variable -in a HTML comment.
Rule #1 -HTML Encode Before Inserting Untrusted Data into HTML Element Content In this rule, OWASP recommends that developers encode HTML before inserting it into HTML content. To illustrate this point, OWASP gives two use cases and we implemented them with Hop. js. First, developers can use an untrusted user value -contained in a variable untrustedVar -inside the content of the structural HTML tag such a <div>. In the following code, the variable untrustedVar is inserted inside the content of the HTML <div> tag: The following is an exploit for the above vulnerable code: let untrustedVar= " ><script>alert (\" XSS \") </ script> "; Last, developers can apply an untrusted user data value -contained in a untrustedVar variable -inside the structural body of HTML. 1 let divVar = In the following piece of code, the untrustedVar variable is inside the web application's <body> markup.
Rule #3 -JavaScript Encode Before Inserting Untrusted Data into JavaScript Data Values OWASP advices developers to place untrusted data only inside quoted data values in JavaScript code. To illustrate this point, OWASP gives four use cases. and we implemented them with Hop. js. Derived from these use cases, we implemented seven HTML contexts in Hop. js. First, developers can use an untrusted user data value -contained in a variable untrustedVar -inside simple quoted event handler values. In the following piece of code, the variable untrustedVar is inserted inside simple quoted of a onmouseover event. bodyVar. appendChild (" <div onmouseover= \" x='" + untrustedVar + "'\>" ); 2 return <html> ${ headVar } ${ bodyVar } </ html>; The following is an full encoding URL exploit for the above vulnerable code: 1 %78%73%73%27%22%3 E %3 C %73%63%72%69%70%74%3 E %6 D %61%6 C %69 2 %63%69%6 F %75%731%3 D %70%72%6 F %6 D %70%74%28%22%70%61%73 3 %73%77%6 F %72%64%22%29%3 B %6 D %61%6 C %69%63%69%6 F %75%732 4 %3 D %70%72%6 F %6 D %70%74%28%22 login %22%29%3 B %61%6 C %65%72 5 %74%28%6 D %61%6 C %69%63%69%6 F %75%731%2 B %22%3 A %22%2 B %6 D 6 %61%6 C %69%63%69%6 F %75%732%29%3 B %3 C %2 F %73%63%72%69%70 7 %74%3 E 8 // Decoded version 9 xss'" ><script>malicious1=prompt (" password ") ; 10 malicious2=prompt (" login ") ; 11 alert ( malicious1 %2 B ":"%2 Bmalicious2 );</ script> Second, developers can use an untrusted user data value -contained in a variable untrustedVar -inside double quoted event handler values.
In the following piece of code, the variable untrustedVar is inserted inside double quoted of a onmouseover event. 1 bodyVar. appendChild (" <div onmouseover= \" x= "+ untrustedVar +" \"\ >"); 2 return <html> ${ headVar } ${ bodyVar } </ html>; The following is an exploit for the above vulnerable code: 1" onclick=alert (" xss ") >click< / div> Third, developers can use an untrusted user data value -contained in a variable untrustedVar -inside simple quoted string and used in JavaScript script. In the following piece of code, the variable untrustedVar is inserted inside simple quoted of an alert box. 1 let scriptVar = <script / >; 2 scriptVar. appendChild (" alert('"+ untrustedVar +"')"); 3 return <html> ${ headVar } ${ scriptVar } ${ bodyVar }</ html> The following is an exploit for the above vulnerable code: normal')</ script><script>alert (" xss ") </ script><script> Fourth, developers can use an untrusted user data value -contained in a variable untrustedVar -inside double quoted string and used in JavaScript script.
In the following piece of code, the variable untrustedVar is inserted inside double quoted of an alert box. 1 let scriptVar = <script / >; 2 scriptVar. appendChild (" alert (\" "+ untrustedVar +" \") "); 3 return <html> ${ headVar } ${ scriptVar } ${ bodyVar }</ html> The following is an exploit for the above vulnerable code: 1 normal ")</ script><button onafterscriptexecute= 2 alert (1) ><script>1< / script> Fifth, developers can use an untrusted user data value -contained in a variable untrustedVar -inside JavaScript simple quoted assignments. In the following piece of code, the variable untrustedVar is inserted between simple quoted to define the value of the variable x. 1 let scriptVar = <script / >; 2 scriptVar. appendChild ( " x= '" + untrustedVar + "'" ); 3 return <html> ${ headVar } ${ scriptVar } ${ bodyVar }</ html> The following is an exploit for the above vulnerable code: 1 3'; data_user=prompt (" First Name ") ; 2 alert ( data_user ); y='3 Sixth, developers can use an untrusted user data value -contained in a variable untrustedVar -inside JavaScript double quoted assignments.
In the following piece of code, the variable untrustedVar is inserted between double quoted to define the value of the variable x. 1 let scriptVar = <script / >; 2 scriptVar. appendChild ( " x= \" " + untrustedVar + " \" "); 3 return <html> ${ headVar } ${ scriptVar } ${ bodyVar }</ html> The following is an exploit for the above vulnerable code: 1 xss "; data_user=prompt (" xss "); y=data_user; 2 console. log (y); z= " xss Finally, OWASP warns to never use unreliable data as input to built-in javascript functions such as setInterval. However, any developer can use the following format: 1 let scriptVar = <script / >; 2 scriptVar. appendChild ( " window. setInterval ( '" + untrustedVar + "' );" ); 3 return <html> ${ headVar } ${ scriptVar } ${ bodyVar } </ html> The following is an exploit for the above vulnerable code: The following is an exploit for the above vulnerable code: 1 ;} @keyframes x{}</ style> 2 <xss style= " animation-name:x " onanimationend= 3 " alert('xss ')" >< / xss> Second, developers can use an untrusted user data value -contained in a variable untrustedVar -inside simple quoted CSS property value.
appendChild (" <a href= " + untrustedVar + 2 " >link< / a> "); 3 return <html> ${ headVar } ${ bodyVar } </ html>; The following is an exploit -that mixed percentencoding and HTML entity encoding -for the above vulnerable code: 1 javascript: %26%2397%26%23108%26%23101%26%23114%26 2 %23116%26%2340%26%2334%26%23120%26%23115%26%23115 3 %26%2334%26%2341; 4 // Decoded version 5 javascript:alert (" xss ") 4 Hashed-AST Technique (PLP) Once that the dataset is built, it can be used to train a deep learning model. However, since the dataset is composed by source code files, a representation strategy is needed. To achieve this goal, we followed the AST-based approach presented by Code2Vec  (Alon et al. , 2019). Specifically, this representation transverse the AST of a piece of code (i. e. file) in order to obtain all the possible paths between leafs.
• maxContext: limits the maximum number of triplets used to represent a piece of code. Regarding the deep learning model (Figure  5 ), we also use the one used in Code2Vec but changing its output layer to a sigmoid function. In short, the triplets are input into an embedding layer whose output goes into a fully-connected layer. Also, an attention layer is used to learn which paths between leafs 4 The source code will be available at https://gitlab. inria. fr/deep-learning-applied-on-web-andiot-security are more important to detect if a piece of code is affected by XSS. At the end, an output sigmoid layer is used to predict is the piece of code is safe or unsafe. A detailed description of the model can be found at  (Alon et al. , 2019).
Evaluation Our evaluation process aims to compare the impact of multi-tier languages on Hashed-AST models of supervised deep learning -to detect XSS -with single-tier language. We use Hop. js as a multi-tier language, and Node. js as a single-tier language. As explained in Section 3. 1, to create the dataset we implement a source code generator for Hop. js whereas we modify a Node. js generator implemented by a previous paper  (Maurel et al. , 2021)  to translate into Node. js the Hop. js generated samples. In this section, we explain the preprocessing step of the database and the experimental protocol (Section 5. 1), then, we present and discuss the evaluation results (Section 5. 2).
Evaluation Process This section explains the preprocessing steps required by the Hop. js and Node. js databases to be "understandable" for the deep learning model. As shown in Table  1 , we split the databases into training (70% of the samples), validation (15%) and testing (15%). To prevent any possible similarities between the generated Hop. js samples, we randomly rename all variables and function names of the datasets. As explained in Section 4, the Hashed-AST based representation that we employ has two hyperparameter: maxPath length/width, and maxContext. For maxPath we experiment with several values,  namely, 10, 20, 30, 50, 80, 130, 210 and 550. Similarly, for maxContext, we used 100, 200, 300, 500, 800, 1300, 2100, 3400 and 5500. By combining the eight maxPath values with the nine values of maxContext, we train 72 models on the training set for Hop.
Evaluation Results In this section, we present the results of our experiment. Due to space constraints, we cannot present all the results obtained. The complete results are available online at https://www. sendgb. com/upload/ ?utm_source=EFOMAhJfGZb. We analyze the precision, recall, and f-measure values obtained during the validation and training phases for both Hop. js and Node. js. Precision distributions analysis Figure  6a  shows the precision distributions of Hop. js and Node. js obtained by the 144 models evaluated with the validation and the testing dataset. For Hop. js, the precision results between the evaluation and the testing phase are very similar. The medians for these distributions are near 72%. Moreover, 25% of the models trained have a high precision between 99% and 86%. Concerning Node.
js (Figure  6c ), the validation and the testing dataset are very similar. The medians for these distributions are near 84%, and, their maximum f-measure achieved is around 94%. In fact, 25% of the models trained have a high f-measure with values between 89% and 94%. Concerning the Node. js f-measure distributions, the evaluation and testing phases' results are also similar. The medians for these distributions are near 90%, and their maximum f-measure achieved are around 97. 50%. The upper 25% of the models have a fmeasure ranging 96% and 98%. To claim any statistically significant difference of these results, a statistically test is needed. We employ the Wilcoxon rank-sum non-parametric test with a probability of error of α = 0. 05. We start by analyzing if there is any significant statistically difference between the results of the evaluation and testing phases.
Related Work New deep learning applications on speech recognition and natural languages have motivated recent research in software engineering and cybersecurity communities to apply deep learning to understand vulnerable code patterns and semantics, characterising vulnerable codes. Lin et al. (Lin et al. , 2020)   Mitch  (Calzavara et al. , 2019 ) is a prototype that uses machine learning to black-box detection of CSRF vulnerability. It tries to identify sensi-tive HTTP requests that require protection against CSRF by manually labelling HTTP requests sent from web applications as sensitive or insensitive HTTP requests. Neutaint  (She et al. , 2020)  uses AFL fuzzer on programs to generate a list of couples of sources and sinks. Instead of representing statically source code in a vector, Neutaint tries to predict the corresponding taint sinks with a neural network for the specified program.
Compared to dynamic taint analysis, the tracked information flow is not obtained from the program's execution but the neural network. VulDeePecker  (Li et al. , 2018b)  uses BLSTM neural networks to detect buffer error (i. e. , CWE-119) and resource management errors (i. e. , CWE-399) related to library/API function calls on C and C++ source code. VulDeePecker used two datasets maintained by the NIST and the SARD project related to buffer and resource management errors in C and C++. Similarly to VulDeePecker, SySeVR  (Li et al. , 2018a)  uses deep learning to detect vulnerabilities in C/C++ intra-procedural source code using program slicing and Word2vec. As datasets, they used the Software Assurance Reference Data set (SARD) project. DeepXSS  (Fang et al. , 2018)  proposes an XSS payload detection model based on long-short term memory (LSTM) recurrent neural networks.
COD-DLE  (Abaimov and Bianchi, 2019 ) is a deep learningbased intrusion detection prototype to malicious payload related to SQLI and XSS. DeepXSS and COD-DLE learn the difference between a potentially malicious input, which a malicious user can inject into user-controllable input of a web application, from a legitimate input from an ordinary user. Therefore, this type of detector can be used to validate whether user input is vulnerable to XSS or secure before the web application uses it in its program. Unlike our work, the detectors, which we trained, analyze source code that uses input controllable by web application users. They can predict whether a web application is vulnerable to XSS or secure. Melicher et al. (Melicher et al. , 2021)  investigate whether machine learning to detect DOM XSS vulnerabilities.
They combine Machine Learning and Taint tracking analyse to reduce the cost of standalone taint tracking. MLPXSS  (Mokbal et al. , 2019)  proposes a neural network-based multilayer perceptron (MLP) to detect XSS attacks. This prototype uses a list of malicious websites and benign websites to generate a raw database. From this database are extracted URL, Javascript, and HTML features, Differently from our work, MLPXSS and Melicher et al. (Melicher et al. , 2021)  are focused only on client-side code. Moreover, in MLPXSS, the contexts that link the Javascript code, the URLs, and HTML are lost by extracting features independent of each other. Zhang et al. (Zhang et al. , 2020)   Shar and Tan  (Shar and Tan, 2013)  propose an approach to predict whether specific program statements are potentially vulnerable to SQLI or XSS.
Conclusion In this work, we explore the differences in the XSS detection learning process of Hashed-AST based techniques by using single-tier and multi-tier languages, Node. js and Hop. js. We generated 144 models in one database including HTML/Javascript and CSS as code in Hop. js and 144 models in a database that includes HTML/Javascript and CSS as text. Hop. js obtained a better recall than Node. js despite the lower precision. This implies that our experiments have not shown a major impact on XSS detectors based on deep learning using multitier ASTs compared to ASTs for Node. js. Our results are promising since they are better than popular static analyzers for JavaScript XSS as shown in previous works  (Maurel et al. , 2021; App-Scan, ). For now, our results are based on synthetic databases and we leave as future wok the creation of a database to detect XSS in real-world web applications.
Background: eHealth literacy is emerging as a crucial concept for promoting patient self-management in an overloaded hospital system. However, to the best of our knowledge, no tool currently exists to measure the level of eHealth literacy among French-speaking people. The eHealth Literacy Scale (eHEALS) is an easy-to-administer 8-item questionnaire (5-point Likert scale, ranging from strongly disagree to strongly agree) that has already been translated into many languages. Currently, it is the most cited questionnaire in the literature.
Second, currently, it is the most widely used scale for measuring eHealth literacy in international scientific literature  [26]. This tool has been translated into different languages over the past 10 years  [27] [28] [29] [30] [31] [32] [33] [34] [35] [36] [37] [38] [39]. This shows that it can be used in various languages and cultural contexts. However, currently, its French translation does not exist. Furthermore, one of the advantages of eHEALS is that it can be adapted to different populations and different contexts. The scale was administered to different categories of individuals, such as older people  [40] , young adults  [41] , nursing students  [42] , and teenagers  [43].
Step 1: Translation of eHEALS Into French by a Process of Double Reverse Translation-Preparation of a Preliminary Version We have been authorized to translate the original eHEALS scale by its authors  [7]. After authorization, we performed a double reverse translation of the eHEALS by 2 professional translators who had French as their native language, independently of each other. This method is considered "ideal for drafting the psychological instrument" (our translation; p665)  [53]. Then, the 2 French versions obtained were retranslated into English by 2 professional translators who had English as their native language and had not seen the original version, again independently of each other. In total, 2 French versions and 2 preliminary English versions were produced at the end of this phase.
Step 2: Validation by a Committee of Experts A committee of 4 experts, 3 (75%) of whom are authors of the manuscript, consisting of 1 (25%) expert in neuropsychology, 1 (25%) expert in cognitive psychology, and 2 (50%) other experts in ergonomics, met to examine the quality of the translations and agree on the best version. To do so, they compared the different translated versions with the original English version, taking into account the French cultural context and checking the clarity of the language. This committee made some minor changes to the selected items. A French version of eHEALS (F-eHEALS) was established after the committee's intervention. The committee members discussed in detail the translation of the term health resources. The suggestions for translation were as follows: "ressources en santé," "ressources sur la santé," or "ressources de santé.