[jira] [Comment Edited] (ATLAS-3014) Could not transfer artifact org.apache:apache:xml:site_en:17
[
https://issues.apache.org/jira/browse/ATLAS-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136324#comment-17136324
]
yangchengkai edited comment on ATLAS-3014 at 6/16/20, 5:52 AM:
---
I got the similar error too.
I solve this problem by set
<{color:#0033b3}properties{color}>
<{color:#0033b3}skipTests{color}>true
<{color:#0033b3}skipSite{color}>true
{color:#0033b3}in docs's pom(atlas-docs) file.{color}
was (Author: 18810276...@163.com):
I got the simlie error too.
I solve this problem by set
<{color:#0033b3}properties{color}>
<{color:#0033b3}skipTests{color}>true
<{color:#0033b3}skipSite{color}>true
{color:#0033b3}in docs's pom(atlas-docs) file.{color}
> Could not transfer artifact org.apache:apache:xml:site_en:17
>
>
> Key: ATLAS-3014
> URL: https://issues.apache.org/jira/browse/ATLAS-3014
> Project: Atlas
> Issue Type: Bug
> Components: atlas-webui
>Affects Versions: 1.1.0
>Reporter: shawn dang
>Priority: Major
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.7:site (default) on project
> atlas-docs: SiteToolException: The site descriptor cannot be resolved from
> the repository: ArtifactResolutionException: Unable to locate site
> descriptor: Could not transfer artifact org.apache:apache:xml:site_en:17
> from/to apache.snapshots.repo
> (https://repository.apache.org/content/groups/snapshots):
> sun.security.validator.ValidatorException: PKIX path validation failed:
> java.security.cert.CertPathValidatorException: validity check failed
> [ERROR] org.apache:apache:xml:17
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] alimaven (http://maven.aliyun.com/nexus/content/groups/public/,
> releases=true, snapshots=false),
> [ERROR] hortonworks.repo
> (http://repo.hortonworks.com/content/repositories/releases, releases=true,
> snapshots=false),
> [ERROR] apache.snapshots.repo
> (https://repository.apache.org/content/groups/snapshots, releases=true,
> snapshots=true),
> [ERROR] apache-staging
> (https://repository.apache.org/content/groups/staging/, releases=true,
> snapshots=true),
> [ERROR] default (https://repository.apache.org/content/groups/public/,
> releases=true, snapshots=true),
> [ERROR] java.net-Public (https://maven.java.net/content/groups/public/,
> releases=true, snapshots=true),
> [ERROR] repository.jboss.org-public
> (https://repository.jboss.org/nexus/content/groups/public, releases=true,
> snapshots=true),
> [ERROR] typesafe (http://repo.typesafe.com/typesafe/releases/,
> releases=true, snapshots=true),
> [ERROR] apache.snapshots (http://repository.apache.org/snapshots,
> releases=false, snapshots=true)
> [ERROR] : NotBefore: Sun Oct 07 20:00:00 EDT 2018
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :atlas-docs
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ATLAS-3014) Could not transfer artifact org.apache:apache:xml:site_en:17
[
https://issues.apache.org/jira/browse/ATLAS-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136324#comment-17136324
]
yangchengkai commented on ATLAS-3014:
-
I got the simlie error too.
I solve this problem by set
<{color:#0033b3}properties{color}>
<{color:#0033b3}skipTests{color}>true
<{color:#0033b3}skipSite{color}>true
{color:#0033b3}in docs's pom(atlas-docs) file.{color}
> Could not transfer artifact org.apache:apache:xml:site_en:17
>
>
> Key: ATLAS-3014
> URL: https://issues.apache.org/jira/browse/ATLAS-3014
> Project: Atlas
> Issue Type: Bug
> Components: atlas-webui
>Affects Versions: 1.1.0
>Reporter: shawn dang
>Priority: Major
>
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.7:site (default) on project
> atlas-docs: SiteToolException: The site descriptor cannot be resolved from
> the repository: ArtifactResolutionException: Unable to locate site
> descriptor: Could not transfer artifact org.apache:apache:xml:site_en:17
> from/to apache.snapshots.repo
> (https://repository.apache.org/content/groups/snapshots):
> sun.security.validator.ValidatorException: PKIX path validation failed:
> java.security.cert.CertPathValidatorException: validity check failed
> [ERROR] org.apache:apache:xml:17
> [ERROR]
> [ERROR] from the specified remote repositories:
> [ERROR] alimaven (http://maven.aliyun.com/nexus/content/groups/public/,
> releases=true, snapshots=false),
> [ERROR] hortonworks.repo
> (http://repo.hortonworks.com/content/repositories/releases, releases=true,
> snapshots=false),
> [ERROR] apache.snapshots.repo
> (https://repository.apache.org/content/groups/snapshots, releases=true,
> snapshots=true),
> [ERROR] apache-staging
> (https://repository.apache.org/content/groups/staging/, releases=true,
> snapshots=true),
> [ERROR] default (https://repository.apache.org/content/groups/public/,
> releases=true, snapshots=true),
> [ERROR] java.net-Public (https://maven.java.net/content/groups/public/,
> releases=true, snapshots=true),
> [ERROR] repository.jboss.org-public
> (https://repository.jboss.org/nexus/content/groups/public, releases=true,
> snapshots=true),
> [ERROR] typesafe (http://repo.typesafe.com/typesafe/releases/,
> releases=true, snapshots=true),
> [ERROR] apache.snapshots (http://repository.apache.org/snapshots,
> releases=false, snapshots=true)
> [ERROR] : NotBefore: Sun Oct 07 20:00:00 EDT 2018
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR] mvn -rf :atlas-docs
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (ATLAS-3401) Maven Package Failure
[ https://issues.apache.org/jira/browse/ATLAS-3401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136320#comment-17136320 ] yangchengkai commented on ATLAS-3401: - This should be some network problems.You can copy and paste the url (the url you stucked in) in web browser to check if this is a maven network problem. Also,if you from China like me,I think you should set aliyun repo in your ~/.m2/settings.xml file.And set your proxy in ~/.m2/settings.xml too. > Maven Package Failure > - > > Key: ATLAS-3401 > URL: https://issues.apache.org/jira/browse/ATLAS-3401 > Project: Atlas > Issue Type: Bug >Reporter: duqunxing >Priority: Blocker > Attachments: image-2019-09-06-14-27-58-626.png, > image-2019-09-06-14-28-25-894.png > > > when package ,the progress is always stuck here. > windows10 > jdk8 > maven3.6.2 > > !image-2019-09-06-14-27-58-626.png! > !image-2019-09-06-14-28-25-894.png! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ATLAS-3166) Exception while starting Atlas with hbase
[ https://issues.apache.org/jira/browse/ATLAS-3166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17136314#comment-17136314 ] yangchengkai commented on ATLAS-3166: - This seems to be some solr and zookeeper compatible problems.I solve this problem by update my solr to 8.5.2 and my zookeeper to 3.5.8. [incompatibility-between-solr-7-7-1-web-admin-and-zookeeper-3-5-5|https://stackoverflow.com/questions/56786300/incompatibility-between-solr-7-7-1-web-admin-and-zookeeper-3-5-5] > Exception while starting Atlas with hbase > - > > Key: ATLAS-3166 > URL: https://issues.apache.org/jira/browse/ATLAS-3166 > Project: Atlas > Issue Type: Bug > Components: atlas-core >Affects Versions: 2.0.0 > Environment: dev >Reporter: Chaitra Rao >Priority: Critical > > When I try to start Atlas (2.0.0-SNAPSHOT), I get the following error - > > > 2019-04-24 18:54:34,637 INFO - [main:] ~ Server starting with TLS ? false on > port 21000 (Atlas:217) > 2019-04-24 18:54:34,637 INFO - [main:] ~ < > (Atlas:218) > 2019-04-24 18:54:35,259 INFO - [main:] ~ No authentication method > configured. Defaulting to simple authentication (LoginProcessor:102) > 2019-04-24 18:54:35,399 WARN - [main:] ~ Unable to load native-hadoop > library for your platform... using builtin-java classes where applicable > (NativeCodeLoader:60) > 2019-04-24 18:54:35,433 INFO - [main:] ~ Logged in user root (auth:SIMPLE) > (LoginProcessor:77) > 2019-04-24 18:54:35,970 INFO - [main:] ~ Not running setup per configuration > atlas.server.run.setup.on.start. (SetupSteps$SetupRequired:189) > 2019-04-24 18:54:48,714 WARN - [main:] ~ > org.apache.solr.client.solrj.impl.Krb5HttpClientBuilder is configured without > specifying system property 'java.security.auth.login.config' > (Krb5HttpClientBuilder:142) > 2019-04-24 18:54:48,950 INFO - [main:] ~ Failed to obtain graph instance, > retrying 3 times, error: java.lang.IllegalArgumentException: Could not > instantiate implementation: org.janusgraph.diskstorage.solr.Solr6Index > (AtlasGraphProvider:100) > 2019-04-24 18:55:19,029 WARN - [main:] ~ > org.apache.solr.client.solrj.impl.Krb5HttpClientBuilder is configured without > specifying system property 'java.security.auth.login.config' > (Krb5HttpClientBuilder:142) > 2019-04-24 18:55:19,035 WARN - [main:] ~ Failed to obtain graph instance on > attempt 1 of 3 (AtlasGraphProvider:118) > java.lang.IllegalArgumentException: Could not instantiate implementation: > org.janusgraph.diskstorage.solr.Solr6Index > at > org.janusgraph.util.system.ConfigurationUtil.instantiate(ConfigurationUtil.java:64) > at org.janusgraph.diskstorage.Backend.getImplementationClass(Backend.java:476) > at org.janusgraph.diskstorage.Backend.getIndexes(Backend.java:463) > at org.janusgraph.diskstorage.Backend.(Backend.java:148) > at > org.janusgraph.graphdb.configuration.GraphDatabaseConfiguration.getBackend(GraphDatabaseConfiguration.java:1840) > at > org.janusgraph.graphdb.database.StandardJanusGraph.(StandardJanusGraph.java:138) > at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:160) > at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:131) > at org.janusgraph.core.JanusGraphFactory.open(JanusGraphFactory.java:111) > at > org.apache.atlas.repository.graphdb.janus.AtlasJanusGraphDatabase.getGraphInstance(AtlasJanusGraphDatabase.java:165) > at > org.apache.atlas.repository.graphdb.janus.AtlasJanusGraphDatabase.getGraph(AtlasJanusGraphDatabase.java:263) > at > org.apache.atlas.repository.graph.AtlasGraphProvider.getGraphInstance(AtlasGraphProvider.java:52) > at > org.apache.atlas.repository.graph.AtlasGraphProvider.retry(AtlasGraphProvider.java:114) > at > org.apache.atlas.repository.graph.AtlasGraphProvider.get(AtlasGraphProvider.java:102) > at > org.apache.atlas.repository.graph.AtlasGraphProvider$$EnhancerBySpringCGLIB$$375c3cc3.CGLIB$get$1() > at > org.apache.atlas.repository.graph.AtlasGraphProvider$$EnhancerBySpringCGLIB$$375c3cc3$$FastClassBySpringCGLIB$$86ea7f4c.invoke() > at > org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:228) > at > org.springframework.context.annotation.ConfigurationClassEnhancer$BeanMethodInterceptor.intercept(ConfigurationClassEnhancer.java:358) > at > org.apache.atlas.repository.graph.AtlasGraphProvider$$EnhancerBySpringCGLIB$$375c3cc3.get() > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at >
[jira] [Created] (ATLAS-3843) why there can only be one active server
liang jie created ATLAS-3843: Summary: why there can only be one active server Key: ATLAS-3843 URL: https://issues.apache.org/jira/browse/ATLAS-3843 Project: Atlas Issue Type: Wish Components: atlas-core Reporter: liang jie why there can only be one active server will performance problem occurs -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ATLAS-3842) Docker image failing
[
https://issues.apache.org/jira/browse/ATLAS-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hannah Amundson updated ATLAS-3842:
---
Affects Version/s: 2.0.0
> Docker image failing
>
>
> Key: ATLAS-3842
> URL: https://issues.apache.org/jira/browse/ATLAS-3842
> Project: Atlas
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Hannah Amundson
>Priority: Major
>
> The Dockerfile in dev-tools is not working. I keep getting this error:
> {code:java}
> Failed to execute goal org.codehaus.mojo:findbugs-maven-plugin:3.0.5:findbugs
> (findbugs) on project atlas-webapp: Execution findbugs of goal
> org.codehaus.mojo:findbugs-maven-plugin:3.0.5:findbugs failed: Java returned:
> 137 -> [Help 1]
> #11 519.5 [ERROR]
> #11 519.5 [ERROR] To see the full stack trace of the errors, re-run Maven
> with the -e switch.
> #11 519.5 [ERROR] Re-run Maven using the -X switch to enable full debug
> logging.
> #11 519.5 [ERROR]
> #11 519.5 [ERROR] For more information about the errors and possible
> solutions, please read the following articles:
> #11 519.5 [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> #11 519.5 [ERROR]
> #11 519.5 [ERROR] After correcting the problems, you can resume the build
> with the command
> #11 519.5 [ERROR] mvn -rf :atlas-webapp
> {code}
> ```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ATLAS-3842) Docker image failing
[
https://issues.apache.org/jira/browse/ATLAS-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hannah Amundson updated ATLAS-3842:
---
Labels: Docker atlas build docker maven mvn (was: )
> Docker image failing
>
>
> Key: ATLAS-3842
> URL: https://issues.apache.org/jira/browse/ATLAS-3842
> Project: Atlas
> Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Hannah Amundson
>Priority: Major
> Labels: Docker, atlas, build, docker, maven, mvn
>
> The Dockerfile in dev-tools is not working. I keep getting this error:
> {code:java}
> Failed to execute goal org.codehaus.mojo:findbugs-maven-plugin:3.0.5:findbugs
> (findbugs) on project atlas-webapp: Execution findbugs of goal
> org.codehaus.mojo:findbugs-maven-plugin:3.0.5:findbugs failed: Java returned:
> 137 -> [Help 1]
> #11 519.5 [ERROR]
> #11 519.5 [ERROR] To see the full stack trace of the errors, re-run Maven
> with the -e switch.
> #11 519.5 [ERROR] Re-run Maven using the -X switch to enable full debug
> logging.
> #11 519.5 [ERROR]
> #11 519.5 [ERROR] For more information about the errors and possible
> solutions, please read the following articles:
> #11 519.5 [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> #11 519.5 [ERROR]
> #11 519.5 [ERROR] After correcting the problems, you can resume the build
> with the command
> #11 519.5 [ERROR] mvn -rf :atlas-webapp
> {code}
> ```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (ATLAS-3842) Docker image failing
[
https://issues.apache.org/jira/browse/ATLAS-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hannah Amundson updated ATLAS-3842:
---
Description:
The Dockerfile in dev-tools is not working. I keep getting this error:
{code:java}
Failed to execute goal org.codehaus.mojo:findbugs-maven-plugin:3.0.5:findbugs
(findbugs) on project atlas-webapp: Execution findbugs of goal
org.codehaus.mojo:findbugs-maven-plugin:3.0.5:findbugs failed: Java returned:
137 -> [Help 1]
#11 519.5 [ERROR]
#11 519.5 [ERROR] To see the full stack trace of the errors, re-run Maven with
the -e switch.
#11 519.5 [ERROR] Re-run Maven using the -X switch to enable full debug logging.
#11 519.5 [ERROR]
#11 519.5 [ERROR] For more information about the errors and possible solutions,
please read the following articles:
#11 519.5 [ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
#11 519.5 [ERROR]
#11 519.5 [ERROR] After correcting the problems, you can resume the build with
the command
#11 519.5 [ERROR] mvn -rf :atlas-webapp
{code}
```
was:
The Dockerfile in dev-tools is not working. I keep getting this error:
```
Failed to execute goal org.codehaus.mojo:findbugs-maven-plugin:3.0.5:findbugs
*(findbugs)* on project atlas-webapp: *Execution findbugs of goal
org.codehaus.mojo:findbugs-maven-plugin:3.0.5:findbugs failed: Java returned:
137* -> *[Help 1]*
#11 519.5 [*ERROR*]
#11 519.5 [*ERROR*] To see the full stack trace of the errors, re-run Maven
with the *-e* switch.
#11 519.5 [*ERROR*] Re-run Maven using the *-X* switch to enable full debug
logging.
#11 519.5 [*ERROR*]
#11 519.5 [*ERROR*] For more information about the errors and possible
solutions, please read the following articles:
#11 519.5 [*ERROR*] *[Help 1]*
http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
#11 519.5 [*ERROR*]
#11 519.5 [*ERROR*] After correcting the problems, you can resume the build
with the command
#11 519.5 [*ERROR*] *mvn -rf :atlas-webapp*
```
> Docker image failing
>
>
> Key: ATLAS-3842
> URL: https://issues.apache.org/jira/browse/ATLAS-3842
> Project: Atlas
> Issue Type: Bug
>Reporter: Hannah Amundson
>Priority: Major
>
> The Dockerfile in dev-tools is not working. I keep getting this error:
> {code:java}
> Failed to execute goal org.codehaus.mojo:findbugs-maven-plugin:3.0.5:findbugs
> (findbugs) on project atlas-webapp: Execution findbugs of goal
> org.codehaus.mojo:findbugs-maven-plugin:3.0.5:findbugs failed: Java returned:
> 137 -> [Help 1]
> #11 519.5 [ERROR]
> #11 519.5 [ERROR] To see the full stack trace of the errors, re-run Maven
> with the -e switch.
> #11 519.5 [ERROR] Re-run Maven using the -X switch to enable full debug
> logging.
> #11 519.5 [ERROR]
> #11 519.5 [ERROR] For more information about the errors and possible
> solutions, please read the following articles:
> #11 519.5 [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
> #11 519.5 [ERROR]
> #11 519.5 [ERROR] After correcting the problems, you can resume the build
> with the command
> #11 519.5 [ERROR] mvn -rf :atlas-webapp
> {code}
> ```
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (ATLAS-3842) Docker image failing
Hannah Amundson created ATLAS-3842: -- Summary: Docker image failing Key: ATLAS-3842 URL: https://issues.apache.org/jira/browse/ATLAS-3842 Project: Atlas Issue Type: Bug Reporter: Hannah Amundson The Dockerfile in dev-tools is not working. I keep getting this error: ``` Failed to execute goal org.codehaus.mojo:findbugs-maven-plugin:3.0.5:findbugs *(findbugs)* on project atlas-webapp: *Execution findbugs of goal org.codehaus.mojo:findbugs-maven-plugin:3.0.5:findbugs failed: Java returned: 137* -> *[Help 1]* #11 519.5 [*ERROR*] #11 519.5 [*ERROR*] To see the full stack trace of the errors, re-run Maven with the *-e* switch. #11 519.5 [*ERROR*] Re-run Maven using the *-X* switch to enable full debug logging. #11 519.5 [*ERROR*] #11 519.5 [*ERROR*] For more information about the errors and possible solutions, please read the following articles: #11 519.5 [*ERROR*] *[Help 1]* http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException #11 519.5 [*ERROR*] #11 519.5 [*ERROR*] After correcting the problems, you can resume the build with the command #11 519.5 [*ERROR*] *mvn -rf :atlas-webapp* ``` -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Seeking advice on Atlas XSS vulnerabilities
Bolke, Melinda, I think it will help to clarify what I meant by "server-side" and "UI". - server-side: Atlas REST APIs to perform various operations on types/entities/glossaries/.. - UI: a web-application running in a browser which calls Atlas REST APIs to fetch data, render and update data I completely agree on all UI modules to handle HTML escaping appropriately - irrespective of whether they run in browser or server side. Few references to 'server side' in the documents referred in this thread seem to be about servlets/JSP - which are not used in Apache Atlas. If you are suggesting all Atlas REST API responses to escape HTML - I think it is a very bad idea. BTW, none of the documents referred in this thread ask the server REST APIs to perform any escaping for HTML. Regards, Madhan On 6/15/20, 1:48 PM, "Bolke de Bruin" wrote: Hi Keval I'm happy that you will tackle the UI part of it. However, these are not mere UI issues and need to be tackled server side IMHO. This opinion is supported by what the experts say[1] Can you elaborate on how you will approach this? I have not seen a discussion. Cheers Bolke [1] https://security.stackexchange.com/questions/19524/current-best-practices-to-prevent-persistent-xss-attacks/19536 Sent from my iPhone > On 15 Jun 2020, at 19:47, Keval Bhatt wrote: > > Hi Bolke, > > Thanks for the details on the UI issues in rendering entity name and > incorrect value storied for user-defined attributes. I am working on > updating UI to address these issues, will send a patch shortly. > > If you see further issues that require a server-side update, can you please > add specific use case details? > > Thanks > >> On Fri, Jun 12, 2020 at 2:15 PM Bolke de Bruin wrote: >> >> Hi Madhan, >> >> A second order XSS (I.e. stored) can be executed against Atlas quite >> easily. If you create an entity with a name like >> >> “> >> >> You will get an alert when clicking “edit” and you will get artifacts all >> over the place stemming from the closing ‘“>’. And there are probably other >> areas where I can do this. Given the fact I can almost store arbitrary >> sizes into Atlas it does not take a lot of imagination to think of a rogue >> service adding an entity (or something else) with a malicious payload and >> then just wait for a user to pick it up. >> >> This is not an “XSS in the UI”. OWASP states that “ DOM Based XSS (or as >> it is called in some texts, “type-0 XSS” or “CLIENT SIDE XSS”) is an XSS >> attack wherein the attack payload is executed as a result of modifying the >> DOM “environment” in the victim’s browser used by the original client side >> script, so that the client side code runs in an “unexpected” manner. That >> is, the page itself (the HTTP response that is) does not change, but the >> client side code contained in the page executes differently due to the >> malicious modifications that have occurred in the DOM environment. This is >> in contrast to other XSS attacks (stored or reflected), wherein the attack >> payload is placed in the response page (due to a server side flaw). >> >> As shown above I was able to make the server return malicious code by >> storing data and have it returned at a different time. This makes it a >> Stored XSS. OWASP ( >> https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html) >> states that to prevent stored XSS it should be addressed server side. >> >> Note also that the UI deals with escaping differently at different places. >> For example the “user labels” are being escaped (but not properly >> unescaped) on the client side. Entity definitions allow anything. Server >> side validation is not done, so I can easily circumvent the UI and edit the >> request. >> >> I assume that you agree with the fact that bare HTML and JavaScript do not >> really have a place in Atlas definitions or a need? Why not escape data on >> output and make that configurable if really needed? And lets improve the >> CSP headers while we are at it (this is being looked at as you mentioned)? >> >> Cheers >> Bolke >> >> Verstuurd vanaf mijn iPad >> Op 11 jun. 2020 om 02:30 heeft Madhan Neethiraj >> het volgende geschreven: >>> Melinda, >>> >>> As I said earlier, I don't agree on server side escaping HTML characters >> in its input and output. Escaping must be handled by components that are >> prone to issues in dealing with unescaped data. We are discussing potential >> XSS in UI while dealing with data from user/server, which requires UI >> updates to perform necessary escapes. As I said earlier, Keval is already >> looking into this. >>> >>>
Re: Seeking advice on Atlas XSS vulnerabilities
Hi Keval I'm happy that you will tackle the UI part of it. However, these are not mere UI issues and need to be tackled server side IMHO. This opinion is supported by what the experts say[1] Can you elaborate on how you will approach this? I have not seen a discussion. Cheers Bolke [1] https://security.stackexchange.com/questions/19524/current-best-practices-to-prevent-persistent-xss-attacks/19536 Sent from my iPhone > On 15 Jun 2020, at 19:47, Keval Bhatt wrote: > > Hi Bolke, > > Thanks for the details on the UI issues in rendering entity name and > incorrect value storied for user-defined attributes. I am working on > updating UI to address these issues, will send a patch shortly. > > If you see further issues that require a server-side update, can you please > add specific use case details? > > Thanks > >> On Fri, Jun 12, 2020 at 2:15 PM Bolke de Bruin wrote: >> >> Hi Madhan, >> >> A second order XSS (I.e. stored) can be executed against Atlas quite >> easily. If you create an entity with a name like >> >> “> >> >> You will get an alert when clicking “edit” and you will get artifacts all >> over the place stemming from the closing ‘“>’. And there are probably other >> areas where I can do this. Given the fact I can almost store arbitrary >> sizes into Atlas it does not take a lot of imagination to think of a rogue >> service adding an entity (or something else) with a malicious payload and >> then just wait for a user to pick it up. >> >> This is not an “XSS in the UI”. OWASP states that “ DOM Based XSS (or as >> it is called in some texts, “type-0 XSS” or “CLIENT SIDE XSS”) is an XSS >> attack wherein the attack payload is executed as a result of modifying the >> DOM “environment” in the victim’s browser used by the original client side >> script, so that the client side code runs in an “unexpected” manner. That >> is, the page itself (the HTTP response that is) does not change, but the >> client side code contained in the page executes differently due to the >> malicious modifications that have occurred in the DOM environment. This is >> in contrast to other XSS attacks (stored or reflected), wherein the attack >> payload is placed in the response page (due to a server side flaw). >> >> As shown above I was able to make the server return malicious code by >> storing data and have it returned at a different time. This makes it a >> Stored XSS. OWASP ( >> https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html) >> states that to prevent stored XSS it should be addressed server side. >> >> Note also that the UI deals with escaping differently at different places. >> For example the “user labels” are being escaped (but not properly >> unescaped) on the client side. Entity definitions allow anything. Server >> side validation is not done, so I can easily circumvent the UI and edit the >> request. >> >> I assume that you agree with the fact that bare HTML and JavaScript do not >> really have a place in Atlas definitions or a need? Why not escape data on >> output and make that configurable if really needed? And lets improve the >> CSP headers while we are at it (this is being looked at as you mentioned)? >> >> Cheers >> Bolke >> >> Verstuurd vanaf mijn iPad >> Op 11 jun. 2020 om 02:30 heeft Madhan Neethiraj >> het volgende geschreven: >>> Melinda, >>> >>> As I said earlier, I don't agree on server side escaping HTML characters >> in its input and output. Escaping must be handled by components that are >> prone to issues in dealing with unescaped data. We are discussing potential >> XSS in UI while dealing with data from user/server, which requires UI >> updates to perform necessary escapes. As I said earlier, Keval is already >> looking into this. >>> >>> And, I haven't heard yet (from you/Bolke/anyone else) on any server side >> issues that require Atlas server to escape HTML characters in data it >> receives/responds. I strongly suggest to not treat this as a release >> blocker. If anyone thinks it is, please come out with clear use >> cases/examples quickly. >>> >>> Regards, >>> Madhan >>> >>> >>> >>> On 6/10/20, 3:22 PM, "Melinda Crane" wrote: >>> >>> Dear Madhan and Bolke, >>> >>> >>> Are there any updates on this topic? The discussion so far has been >> pretty >>> exciting to see and hear - having the sanitization feature as an >> optional >>> config like Bolke mentioned would be real useful to us (since we know >> our >>> data should never contain html characters), and it seems like it >> would be >>> useful for other companies down the road who have stricter security >>> requirements. Where the sanitization would happen is of course >> completely >>> up to you folks! >>> >>> >>> Cheers, >>> >>> Melinda Crane >>> On Tue, Jun 9, 2020 at 10:46 AM Madhan Neethiraj >> wrote: Bolke, > 1. Filtering input on arrival where the user cannot manipulate it anymore
Re: Seeking advice on Atlas XSS vulnerabilities
Hi Bolke, Thanks for the details on the UI issues in rendering entity name and incorrect value storied for user-defined attributes. I am working on updating UI to address these issues, will send a patch shortly. If you see further issues that require a server-side update, can you please add specific use case details? Thanks On Fri, Jun 12, 2020 at 2:15 PM Bolke de Bruin wrote: > Hi Madhan, > > A second order XSS (I.e. stored) can be executed against Atlas quite > easily. If you create an entity with a name like > > “> > > You will get an alert when clicking “edit” and you will get artifacts all > over the place stemming from the closing ‘“>’. And there are probably other > areas where I can do this. Given the fact I can almost store arbitrary > sizes into Atlas it does not take a lot of imagination to think of a rogue > service adding an entity (or something else) with a malicious payload and > then just wait for a user to pick it up. > > This is not an “XSS in the UI”. OWASP states that “ DOM Based XSS (or as > it is called in some texts, “type-0 XSS” or “CLIENT SIDE XSS”) is an XSS > attack wherein the attack payload is executed as a result of modifying the > DOM “environment” in the victim’s browser used by the original client side > script, so that the client side code runs in an “unexpected” manner. That > is, the page itself (the HTTP response that is) does not change, but the > client side code contained in the page executes differently due to the > malicious modifications that have occurred in the DOM environment. This is > in contrast to other XSS attacks (stored or reflected), wherein the attack > payload is placed in the response page (due to a server side flaw). > > As shown above I was able to make the server return malicious code by > storing data and have it returned at a different time. This makes it a > Stored XSS. OWASP ( > https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html) > states that to prevent stored XSS it should be addressed server side. > > Note also that the UI deals with escaping differently at different places. > For example the “user labels” are being escaped (but not properly > unescaped) on the client side. Entity definitions allow anything. Server > side validation is not done, so I can easily circumvent the UI and edit the > request. > > I assume that you agree with the fact that bare HTML and JavaScript do not > really have a place in Atlas definitions or a need? Why not escape data on > output and make that configurable if really needed? And lets improve the > CSP headers while we are at it (this is being looked at as you mentioned)? > > Cheers > Bolke > > Verstuurd vanaf mijn iPad > > >> Op 11 jun. 2020 om 02:30 heeft Madhan Neethiraj > het volgende geschreven: > > Melinda, > > > > As I said earlier, I don't agree on server side escaping HTML characters > in its input and output. Escaping must be handled by components that are > prone to issues in dealing with unescaped data. We are discussing potential > XSS in UI while dealing with data from user/server, which requires UI > updates to perform necessary escapes. As I said earlier, Keval is already > looking into this. > > > > And, I haven't heard yet (from you/Bolke/anyone else) on any server side > issues that require Atlas server to escape HTML characters in data it > receives/responds. I strongly suggest to not treat this as a release > blocker. If anyone thinks it is, please come out with clear use > cases/examples quickly. > > > > Regards, > > Madhan > > > > > > > > On 6/10/20, 3:22 PM, "Melinda Crane" wrote: > > > >Dear Madhan and Bolke, > > > > > >Are there any updates on this topic? The discussion so far has been > pretty > >exciting to see and hear - having the sanitization feature as an > optional > >config like Bolke mentioned would be real useful to us (since we know > our > >data should never contain html characters), and it seems like it > would be > >useful for other companies down the road who have stricter security > >requirements. Where the sanitization would happen is of course > completely > >up to you folks! > > > > > >Cheers, > > > >Melinda Crane > > > >>On Tue, Jun 9, 2020 at 10:46 AM Madhan Neethiraj > wrote: > >> > >> Bolke, > >> > >>>1. Filtering input on arrival where the user cannot manipulate it > >> anymore (i.e. server) > >> It's not clear what you expect the server to do here? Should HTML > >> characters be escaped in all inputs, before saving the data in its > store? > >> Can you give few examples of server-side manipulation due to unescaped > HTML > >> characters? > >> > >>>2. Encode data on output > >> I think asking the server side to escape all HTML characters in its > >> response is a very bad idea. Consider forcing such a requirement on a > RDBMS > >> - wouldn't this mandate every client to un-escape every column value > >> returned for queries? Can you add references to
[jira] [Assigned] (ATLAS-3841) Response Headers: Code refactoring
[ https://issues.apache.org/jira/browse/ATLAS-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mandar Ambawane reassigned ATLAS-3841: -- Assignee: Mandar Ambawane > Response Headers: Code refactoring > -- > > Key: ATLAS-3841 > URL: https://issues.apache.org/jira/browse/ATLAS-3841 > Project: Atlas > Issue Type: Bug >Reporter: Mandar Ambawane >Assignee: Mandar Ambawane >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ATLAS-3841) Response Headers: Code refactoring
Mandar Ambawane created ATLAS-3841: -- Summary: Response Headers: Code refactoring Key: ATLAS-3841 URL: https://issues.apache.org/jira/browse/ATLAS-3841 Project: Atlas Issue Type: Bug Reporter: Mandar Ambawane -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (ATLAS-3838) Support multiple tag/classification in basic/quick search API
[ https://issues.apache.org/jira/browse/ATLAS-3838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pinal updated ATLAS-3838: - Description: it will allow user to search with multiple tags and the tag attribute filters (attribute should System attributes or attribute which common for all the mentioned tags) > Support multiple tag/classification in basic/quick search API > - > > Key: ATLAS-3838 > URL: https://issues.apache.org/jira/browse/ATLAS-3838 > Project: Atlas > Issue Type: New Feature >Affects Versions: 2.0.0 >Reporter: Pinal >Assignee: Pinal >Priority: Major > Labels: BasicSearch > > it will allow user to search with multiple tags and the tag attribute filters > (attribute should System attributes or attribute which common for all the > mentioned tags) -- This message was sent by Atlassian Jira (v8.3.4#803005)
