Summary
Several SPARQL query builders interpolate values that originate from HTTP request path parameters directly into SPARQL query strings via JS template literals, without escaping or validation. This looks like a security-sensitive bug, so I'm deliberately not including exploit payloads or a working proof-of-concept in this public issue.
Where
serverless/src/shared/getSkosConcept.js — the shortName and altLabel branches pass request-derived values straight through to the query builders below, unescaped.serverless/src/shared/operations/queries/getTriplesForShortNameQuery.jsserverless/src/shared/operations/queries/getTriplesForAltLabelQuery.jsserverless/src/shared/operations/queries/getConceptsQuery.jsserverless/src/shared/operations/queries/getTotalCountQuery.js
These values ultimately come from event.pathParameters in serverless/src/getConcept/handler.js and serverless/src/getConcepts/handler.js (e.g. shortName, altLabel, pattern, conceptScheme), decoded but not sanitized before being embedded inside FILTER(... = LCASE("${value}"))-style string literals.
Why this stands out
The codebase already has serverless/src/shared/escapeSparqlString.js, which is applied to the fullPath branch in getSkosConcept.js (see lines around 162 and 177) — but it is not applied to the shortName/altLabel branches a few lines above, nor to the pattern/conceptScheme values used in getConceptsQuery.js / getTotalCountQuery.js. That inconsistency suggests the escaping requirement was already understood for one code path but missed for the others.
Suggested fix
Apply the existing escapeSparqlString() helper (or equivalent validation, e.g. allowlisting scheme names) consistently to every value interpolated into a SPARQL string literal across these files, not just the fullPath path.
Note
I'd be glad to share a full write-up, including a concrete input that demonstrates the issue, through a private channel — happy to use whatever vulnerability disclosure process NASA prefers (e.g. https://hackerone.com/nasa or https://www.nasa.gov/vulnerability-disclosure-policy/) if that's easier for the team to track.
Summary
Several SPARQL query builders interpolate values that originate from HTTP request path parameters directly into SPARQL query strings via JS template literals, without escaping or validation. This looks like a security-sensitive bug, so I'm deliberately not including exploit payloads or a working proof-of-concept in this public issue.
Where
serverless/src/shared/getSkosConcept.js— theshortNameandaltLabelbranches pass request-derived values straight through to the query builders below, unescaped.serverless/src/shared/operations/queries/getTriplesForShortNameQuery.jsserverless/src/shared/operations/queries/getTriplesForAltLabelQuery.jsserverless/src/shared/operations/queries/getConceptsQuery.jsserverless/src/shared/operations/queries/getTotalCountQuery.jsThese values ultimately come from
event.pathParametersinserverless/src/getConcept/handler.jsandserverless/src/getConcepts/handler.js(e.g.shortName,altLabel,pattern,conceptScheme), decoded but not sanitized before being embedded insideFILTER(... = LCASE("${value}"))-style string literals.Why this stands out
The codebase already has
serverless/src/shared/escapeSparqlString.js, which is applied to thefullPathbranch ingetSkosConcept.js(see lines around 162 and 177) — but it is not applied to theshortName/altLabelbranches a few lines above, nor to thepattern/conceptSchemevalues used ingetConceptsQuery.js/getTotalCountQuery.js. That inconsistency suggests the escaping requirement was already understood for one code path but missed for the others.Suggested fix
Apply the existing
escapeSparqlString()helper (or equivalent validation, e.g. allowlisting scheme names) consistently to every value interpolated into a SPARQL string literal across these files, not just thefullPathpath.Note
I'd be glad to share a full write-up, including a concrete input that demonstrates the issue, through a private channel — happy to use whatever vulnerability disclosure process NASA prefers (e.g. https://hackerone.com/nasa or https://www.nasa.gov/vulnerability-disclosure-policy/) if that's easier for the team to track.