Am Mi., 22. Jan. 2020 um 21:51 Uhr schrieb Daniel Dekany < [email protected]>:
> Off hand, I have no objections. Though I don't yet know exactly how you > imagine it. MemberSelector.parse and MemberSelector.isIgnoredLine are > public. > The "@" <rule> <upperBoundType> syntax parsing is not public. I see. > Do > you intend to use that in your application? > My naive thought was "cool there is already a textual format which let me maintain a list. So I just create a similar file and adapt it to our needs instead of reinventing the wheel". Ok, if this is not meant to be public we can build our own. > > On Wed, Jan 22, 2020 at 12:45 AM Christoph Rüger <[email protected]> > wrote: > > > Daniel, do you have any objections to refactoring the file-parsing-code > in > > DefaultMemberAccessPolicy to be reusable? e.g. to use it against an own > > file which is structured like DefaultMemberAccessPolicy-rules? Even when > > using WhitelistMemberAccessPolicy it would be great to maintain this in a > > file like DefaultMemberAccessPolicy-rules > > > > Sure, one could write own logic like this, but why not built upon this > one > > if someone wants to maintain the list in a text file. > > > > > > Am Do., 16. Jan. 2020 um 23:07 Uhr schrieb Christoph Rüger < > > [email protected]>: > > > > > > > > Am Do., 16. Jan. 2020 um 07:49 Uhr schrieb Daniel Dekany < > > > [email protected]>: > > > > > >> Quick idea... What if you create a MemberAccessPolicy implementation > > that > > >> just delegates to the actual WhiltlistAccessPolicy, which is in an > > >> AtomicReference field. When something registers a new piece a > whitelist, > > >> you fully recreate this embedded WhitelistAcessPolicy. I guess such > even > > >> would be rare considering the whole lifecycle of the application. > > >> > > > > > > Good idea, thanks. > > > > > > > > >> > > >> On Wed, Jan 15, 2020 at 9:47 AM Christoph Rüger <[email protected] > > > > >> wrote: > > >> > > >> > First of all, great stuff. Also thanks for > > >> > making BeansWrapper.invokeMethod(Object, Method, Object[]) > protected, > > as > > >> > this helps us to monitor method invocations. As you write in a > comment > > >> it > > >> > will be "significant work to put together" a whitelist, but this > will > > >> help > > >> > to do so. Do you think it makes sense to provide a helper method > e.g. > > >> > public String MemberSelector.toSelectorRulesString() which outputs a > > >> String > > >> > which is understood by MemberSelector.parse(String)? Could be > helpful > > >> for > > >> > monitoring in that context to make sure you create such rules > > (strings) > > >> and > > >> > always get the syntax right. > > >> > > > >> > Am Di., 14. Jan. 2020 um 23:40 Uhr schrieb Daniel Dekany < > > >> > [email protected]>: > > >> > > > >> > > And updated it again... I hope I won't find any more things I > missed > > >> to > > >> > > address. > > >> > > > > >> > > Anyway, I think we should start going for a release (in a month or > > >> > > something), so, Christoph, any idea when can you say something > about > > >> the > > >> > > OSGi issues? I don't want to release something where that can't be > > >> > solved. > > >> > > > > >> > > > >> > > > >> > I had a first look at it and try to wrap my head around it. > > >> > Regarding OSGI: I noticed that a Classloader can be passed to e.g. > > >> > MemberSelector.parse(Collection<String>, boolean, ClassLoader) which > > is > > >> > always a good thing for OSGI. > > >> > > > >> > The key thing in OSG is that new Classes (provided by bundles) can > > >> appear > > >> > dynamically at runtime at any point in time. So I think we would > need > > to > > >> > add rules to MemberAccessPolicy dynamically. Since > > >> > MemberSelectorListMemberAccessPolicy.forClass(Class<?>) is made > final > > I > > >> > assume we need to write our own MemberAccessPolicy from scratch (or > > >> > duplicate code from MemberSelectorListMemberAccessPolicy) in order > to > > >> add > > >> > MemberSelectors dynamically. Right? Or would it be possible to > somehow > > >> > extend MemberSelectorListMemberAccessPolicy / > > >> WhitelistMemberAccessPolicy > > >> > and add MemberSelectors to the internal matchers (e.g. MethodMatcher > > >> etc.) > > >> > from a subclass? > > >> > > > >> > I guess we would like to subclass WhitelistMemberAccessPolicy to > > handle > > >> > dynamic registration of our OSGI stuff (means adding MemberSelectors > > >> > dynamically). > > >> > > > >> > It might be too early as I have not fully understood everything, but > > >> maybe > > >> > you can provide first thoughts. > > >> > > > >> > > > >> > > > >> > > > >> > > On Sat, Jan 11, 2020 at 8:25 PM Daniel Dekany < > > >> [email protected]> > > >> > > wrote: > > >> > > > > >> > > > I have also updated the default member access policy, so the > > tricks > > >> you > > >> > > > tried back then shouldn't work anymore, even if you don't use > your > > >> own > > >> > > > member access policy. But, you still definitely should use your > > own > > >> > > policy, > > >> > > > if users aren't trusted. > > >> > > > > > >> > > > The other API-s and Javadocs were evolved too a bit since then; > I > > >> have > > >> > > > deployed it to the maven repo and updated > > >> > > > https://freemarker.apache.org/builds/fm2 > > >> > > > < > > >> > > > > >> > > > >> > > > https://freemarker.apache.org/builds/fm2/api/freemarker/ext/beans/MemberAccessPolicy.html > > >> > > > > > >> > > > accordingly, > > >> > > > > > >> > > > > > >> > > > On Thu, Jan 2, 2020 at 10:55 PM Christoph Rüger < > > >> [email protected]> > > >> > > > wrote: > > >> > > > > > >> > > >> Am Mi., 1. Jan. 2020 um 22:12 Uhr schrieb Daniel Dekany < > > >> > > >> [email protected]>: > > >> > > >> > > >> > > >> > Guys, > > >> > > >> > > > >> > > >> > I have add MemberAccessPolicy to the API, which you can plug > > >> into a > > >> > > >> > DefaultObjectWrapper (or to any BeansWrapper). I have also > > added > > >> > > >> > WhitelistMemberAccessPolicy, to ease adding a restrictive > > policy. > > >> > > Please > > >> > > >> > take a look. 2.3.30-SNAPSHOT is in the Apache snapshot repo, > as > > >> > usual. > > >> > > >> You > > >> > > >> > can start out from here in API documentation: > > >> > > >> > > > >> > > >> > > > >> > > >> > > >> > > > > >> > > > >> > > > https://freemarker.apache.org/builds/fm2/api/freemarker/ext/beans/MemberAccessPolicy.html > > >> > > >> > > >> > > >> > > >> > > >> Thanks Daniel and happy new year :) > > >> > > >> We will try to test this. Cannot promise how soon we get to it, > > >> but I > > >> > > will > > >> > > >> try my best. > > >> > > >> We will also check how this behaves in our OSGI world. > > >> > > >> > > >> > > >> > > >> > > >> > > > >> > > >> > > > >> > > >> > So please review these, tell if you have any recommendations, > > or > > >> you > > >> > > >> see a > > >> > > >> > way to circumvent this. (One risky thing I see is that we > have > > a > > >> > long > > >> > > >> > deprecated default static instance of DefaultObjectWrapper, > > >> which if > > >> > > >> course > > >> > > >> > doesn't use any custom MemberAccessPolicy. We use that static > > >> > instance > > >> > > >> > internally in FM2 on a lot of places. I will have to review > all > > >> such > > >> > > >> cases, > > >> > > >> > and also make it less probable that they can become > exploitable > > >> > > later.) > > >> > > >> > > > >> > > >> > I will also create a new implementation for > > >> > DefaultMemberAccessPolicy > > >> > > >> > later. The current one does exactly what the old one did. The > > >> only > > >> > > real > > >> > > >> > solution will be still WhitelistMemberAccessPolicy, if > someone > > >> > indeed > > >> > > >> > doesn't trust the template authors. > > >> > > >> > > > >> > > >> > On Tue, Dec 24, 2019 at 6:31 PM Siegfried Goeschl < > > >> > > >> > [email protected]> wrote: > > >> > > >> > > > >> > > >> > > HI Daniel, > > >> > > >> > > > > >> > > >> > > Would it make sense to come up with a separate chapter for > > the > > >> > > >> existing > > >> > > >> > > FreeMarker documentation to explain the things in detail? > > >> > > >> > > > > >> > > >> > > Thanks in advance, > > >> > > >> > > > > >> > > >> > > Siegfried Goeschl > > >> > > >> > > > > >> > > >> > > PS: Last email for today - preparing Christmas dinner :-) > > >> > > >> > > > > >> > > >> > > > On 24.12.2019, at 18:23, Daniel Dekany < > > >> [email protected] > > >> > > > > >> > > >> > wrote: > > >> > > >> > > > > > >> > > >> > > > I responded to your mail that says "The problem described > > in > > >> the > > >> > > >> > article > > >> > > >> > > > was less about arbitrary people but someone who hacked > > >> through > > >> > > other > > >> > > >> > > > security issues to become administrator with temple > editing > > >> > > rights". > > >> > > >> > So I > > >> > > >> > > > thought that the premise there was that people who > > shouldn't > > >> be > > >> > > >> able to > > >> > > >> > > > edit templates become able to do so. But it doesn't mater > > >> how it > > >> > > >> was in > > >> > > >> > > > that case. Because as I said in the linked bug report, > and > > as > > >> > the > > >> > > >> FAQ > > >> > > >> > > says, > > >> > > >> > > > if you allow someone to edit templates with the default > > >> > FreeMarker > > >> > > >> > > > configuration, that's almost like if you allow them to > edit > > >> Java > > >> > > >> files. > > >> > > >> > > So > > >> > > >> > > > whatever your application has right to do (like read the > > >> > password > > >> > > >> file, > > >> > > >> > > > launch missiles, etc.), the templates probably can do as > > >> well. > > >> > The > > >> > > >> > point > > >> > > >> > > of > > >> > > >> > > > discouraging complex/technical logic in templates (not > just > > >> in > > >> > > >> > > FreeMarker) > > >> > > >> > > > was the MVC principle, where you should only put > > presentation > > >> > > logic > > >> > > >> > into > > >> > > >> > > > the templates. > > >> > > >> > > > > > >> > > >> > > > We can't provide a practically useful default > configuration > > >> > that's > > >> > > >> > secure > > >> > > >> > > > if you can't trust people that can edit templates, > because > > >> the > > >> > > >> > whitelist > > >> > > >> > > > content is specific to the concrete application. By > default > > >> ?new > > >> > > is > > >> > > >> not > > >> > > >> > > > restricted (well, it can instantiate TemplatModel-s only, > > but > > >> > that > > >> > > >> > hardly > > >> > > >> > > > saves anyone security wise). The reason ?api is still > > >> disabled > > >> > by > > >> > > >> > default > > >> > > >> > > > is that if someone went through the pain of setting up > > >> > FreeMarker > > >> > > >> to be > > >> > > >> > > > safe(r) (which implies that you do not use the default > > >> > > >> ObjectWrapper, > > >> > > >> > nor > > >> > > >> > > > the default settings for ?new, and you are thoughtful > with > > >> your > > >> > > >> > > > TemplateLoader, as the FAQ says), then the new FreeMarker > > >> > version > > >> > > >> where > > >> > > >> > > > ?api was introduced should not open a new hole on your > > >> system. > > >> > For > > >> > > >> > almost > > >> > > >> > > > all users though, ?api enabled by default would be better > > >> (it's > > >> > > >> mostly > > >> > > >> > to > > >> > > >> > > > allow users to work around TemplateHashModel limitations > > when > > >> > > >> dealing > > >> > > >> > > with > > >> > > >> > > > java.util.Map-s), but I have chosen the safer approach > > when I > > >> > > added > > >> > > >> it. > > >> > > >> > > > > > >> > > >> > > > The unsafeMethods mechanism will be updated, as things > > stand, > > >> > > >> despite > > >> > > >> > > that > > >> > > >> > > > it's not strictly backward compatible. It will be still a > > >> quite > > >> > > >> > pointless > > >> > > >> > > > mechanism. I don't know why was it added by the author > > (some > > >> > 10-15 > > >> > > >> > years > > >> > > >> > > > ago, I think). > > >> > > >> > > > > > >> > > >> > > > On Tue, Dec 24, 2019 at 4:14 PM Siegfried Goeschl < > > >> > > >> > > > [email protected]> wrote: > > >> > > >> > > > > > >> > > >> > > >> Hi Daniel, > > >> > > >> > > >> > > >> > > >> > > >> Not sure about your line of thoughts :-) > > >> > > >> > > >> > > >> > > >> > > >> My understanding > > >> > > >> > > >> > > >> > > >> > > >> * There is a recipe out there how someone can access the > > >> file > > >> > > >> system > > >> > > >> > and > > >> > > >> > > >> the setup was not bad security-wise - only "?api" > built-in > > >> was > > >> > > >> enabled > > >> > > >> > > >> * I think the "?api.class.getResource" and > > >> > > >> > > >> "?api.class.getResourceAsStream" can be marked as unsafe > > >> > method? > > >> > > >> > > >> * I also think that ALLOWS_NOTHING_RESOLVER is not the > > >> default > > >> > > >> > > >> configuration? > > >> > > >> > > >> * I actually tried the published code and it reads my > > >> > > >> "/etc/passwd" :( > > >> > > >> > > >> > > >> > > >> > > >> If the assumptions above are correct - can this > particular > > >> > attack > > >> > > >> be > > >> > > >> > > >> avoided? If so we should react and improve the > > configuration > > >> > ... > > >> > > >> > > >> > > >> > > >> > > >> Thanks in advance, > > >> > > >> > > >> > > >> > > >> > > >> Siegfried Goeschl > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >>> On 24.12.2019, at 11:50, Daniel Dekany < > > >> > [email protected] > > >> > > > > > >> > > >> > > wrote: > > >> > > >> > > >>> > > >> > > >> > > >>> The blog entry might starts its case with a privilege > > >> > escalation > > >> > > >> > > >>> independent of FreeMarker, but the question you got > > during > > >> > your > > >> > > >> > > >>> presentation wasn't about that, I think. But more > > >> importantly, > > >> > > >> some > > >> > > >> > > real > > >> > > >> > > >>> world applications do allow editing templates for users > > who > > >> > > aren't > > >> > > >> > > >>> necessarily some kind of superusers. Right now, after > > they > > >> > > >> realized > > >> > > >> > > that > > >> > > >> > > >>> the problem exists at all, they will have to figure > out a > > >> > > solution > > >> > > >> > > >>> themselves. We are in a much better position to do the > > >> same. > > >> > > >> > > >>> > > >> > > >> > > >>> DOS-ing is certainly less of a concern in general, > though > > >> > > >> > unintentional > > >> > > >> > > >>> DOS-ing (or I guess unintentional) was a problem for > > >> > > >> > > >>> try.freemarker.apache.org in the past. My point there > is > > >> just > > >> > > >> that > > >> > > >> > if > > >> > > >> > > >>> really everyone from the Internet can edit templates, > > then > > >> it > > >> > > will > > >> > > >> > be a > > >> > > >> > > >>> problem, I guess for any practical template language. > > >> > > >> > > >>> > > >> > > >> > > >>> > > >> > > >> > > >>> On Mon, Dec 23, 2019 at 11:55 PM Siegfried Goeschl < > > >> > > >> > > >>> [email protected]> wrote: > > >> > > >> > > >>> > > >> > > >> > > >>>> Hi Daniel, > > >> > > >> > > >>>> > > >> > > >> > > >>>> I guess I need to re-read the FreeMarker documentation > > and > > >> > > >> ticket - > > >> > > >> > > >> having > > >> > > >> > > >>>> said that > > >> > > >> > > >>>> > > >> > > >> > > >>>> * The problem described in the article was less about > > >> > arbitrary > > >> > > >> > people > > >> > > >> > > >> but > > >> > > >> > > >>>> someone who hacked through other security issues to > > become > > >> > > >> > > administrator > > >> > > >> > > >>>> with temple editing rights > > >> > > >> > > >>>> * The people having that skills usually don't have any > > >> > interest > > >> > > >> in > > >> > > >> > > >>>> starting a DOS attack by messing up templates - there > > are > > >> > more > > >> > > >> > > valuable > > >> > > >> > > >>>> things out there ... > > >> > > >> > > >>>> * I think it is pretty much impossible to make > > FreeMarker > > >> > 100% > > >> > > >> > bullet > > >> > > >> > > >>>> proof (tons of features, a lot of code, arbitrary > > >> libraries > > >> > > >> coming > > >> > > >> > > from > > >> > > >> > > >> the > > >> > > >> > > >>>> application) but at least we can check that this > attack > > >> does > > >> > > not > > >> > > >> > work > > >> > > >> > > >> any > > >> > > >> > > >>>> longer > > >> > > >> > > >>>> * From my understanding - usually there a couple of > > >> security > > >> > > >> > > >>>> vulnerabilites leading to complete data breach :-) > > >> > > >> > > >>>> > > >> > > >> > > >>>> Thanks in advance, > > >> > > >> > > >>>> > > >> > > >> > > >>>> Siegfried Goeschl > > >> > > >> > > >>>> > > >> > > >> > > >>>> > > >> > > >> > > >>>>> On 23.12.2019, at 22:30, Daniel Dekany < > > >> > > [email protected] > > >> > > >> > > > >> > > >> > > >> wrote: > > >> > > >> > > >>>>> > > >> > > >> > > >>>>> Hi, > > >> > > >> > > >>>>> > > >> > > >> > > >>>>> In short, allowing untrusted users to edit templates > is > > >> not > > >> > > >> > > supported. > > >> > > >> > > >>>> But, > > >> > > >> > > >>>>> since people do it anyway, 2.3.30 will make an effort > > to > > >> > allow > > >> > > >> > doing > > >> > > >> > > >> that > > >> > > >> > > >>>>> with taking far less risk than what people take now. > > The > > >> > > >> > > >>>> MemberAccessPolicy > > >> > > >> > > >>>>> feature committed in recent days is the start of > that. > > >> > > Actually, > > >> > > >> > you > > >> > > >> > > >>>> could > > >> > > >> > > >>>>> always just use SimpleObjectWrapper (as the FAQ > > states), > > >> but > > >> > > >> > clearly > > >> > > >> > > >>>> that's > > >> > > >> > > >>>>> too limiting for what many (most?) people use > > FreeMarker > > >> > for. > > >> > > >> But > > >> > > >> > > >>>> anyway, I > > >> > > >> > > >>>>> don't believe that a template engine with the > > complexity > > >> of > > >> > > >> > > FreeMarker > > >> > > >> > > >>>> will > > >> > > >> > > >>>>> be ever a good fit for applications where random > people > > >> can > > >> > > edit > > >> > > >> > > >>>> templates. > > >> > > >> > > >>>>> If users are accountable in real life for what they > > did, > > >> > like > > >> > > >> they > > >> > > >> > > are > > >> > > >> > > >>>>> employees at the client, then probably it will be > good > > >> > enough, > > >> > > >> but > > >> > > >> > > not > > >> > > >> > > >>>> for > > >> > > >> > > >>>>> use cases where anyone can edit templates. If nothing > > >> else, > > >> > > you > > >> > > >> > will > > >> > > >> > > be > > >> > > >> > > >>>> too > > >> > > >> > > >>>>> easily DOS-able then. > > >> > > >> > > >>>>> > > >> > > >> > > >>>>> As of the blog entry, see this: > > >> > > >> > > >>>>> https://issues.apache.org/jira/browse/FREEMARKER-124 > > >> > > >> > > >>>>> Here I would add that it's likely that the calls used > > in > > >> the > > >> > > >> blog > > >> > > >> > > entry > > >> > > >> > > >>>>> won't work anymore in 2.3.30. I'm a bit uneasy about > > >> that, > > >> > as > > >> > > >> it's > > >> > > >> > a > > >> > > >> > > >>>>> backward compatibility risk (it won't be just > blocking > > >> that > > >> > > >> single > > >> > > >> > > >>>> method), > > >> > > >> > > >>>>> while it doesn't provide real security. You need a > > >> whitelist > > >> > > of > > >> > > >> > > what's > > >> > > >> > > >>>>> allowed for that (as opposed to a blacklist), and > > that's > > >> > > >> possible > > >> > > >> > to > > >> > > >> > > do > > >> > > >> > > >>>>> with MemberAccessPolicy, but I will also provide an > > >> > > >> implementation > > >> > > >> > to > > >> > > >> > > >>>> help > > >> > > >> > > >>>>> doing that. > > >> > > >> > > >>>>> > > >> > > >> > > >>>>> Also, in the FAQ: > > >> > > >> > > >>>>> > > >> > > >> > > >>>> > > >> > > >> > > >> > > >> > > >> > > > > >> > > >> > > > >> > > >> > > >> > > > > >> > > > >> > > > https://freemarker.apache.org/docs/app_faq.html#faq_template_uploading_security > > >> > > >> > > >>>>> > > >> > > >> > > >>>>> > > >> > > >> > > >>>>> On Mon, Dec 23, 2019 at 7:25 PM Siegfried Goeschl < > > >> > > >> > > >>>>> [email protected]> wrote: > > >> > > >> > > >>>>> > > >> > > >> > > >>>>>> Hi folks, > > >> > > >> > > >>>>>> > > >> > > >> > > >>>>>> During my last presentation I was asked about how > > secure > > >> > > Apache > > >> > > >> > > >>>> Freemarker > > >> > > >> > > >>>>>> is in the context of user editing their templates - > > >> well, > > >> > > hard > > >> > > >> to > > >> > > >> > > say > > >> > > >> > > >>>>>> without knowing the application. > > >> > > >> > > >>>>>> > > >> > > >> > > >>>>>> But I came across an interesting article (see > > >> > > >> > > >>>>>> > > >> > > >> > https://ackcent.com/blog/in-depth-freemarker-template-injection/ > > ) > > >> > > >> > > >> where > > >> > > >> > > >>>>>> the authors successfully hacked a CMS based on > Apache > > >> > > >> FreeMarker > > >> > > >> > > >>>>>> > > >> > > >> > > >>>>>> * As far as I know the UNRESTRICTED_RESOLVER is the > > >> > default? > > >> > > >> Maybe > > >> > > >> > > >>>>>> ALLOWS_NOTHING_RESOLVER would be a better default? > > >> > > >> > > >>>>>> * Enabling "?api" needs to be enabled by developers > > >> which > > >> > is > > >> > > >> fine > > >> > > >> > > >>>>>> * Update the "unsafeMethods.properties" according to > > the > > >> > > >> article? > > >> > > >> > > For > > >> > > >> > > >>>> the > > >> > > >> > > >>>>>> records "java.lang.Thread.suspend()" is duplicated > > >> anyway > > >> > > >> > > >>>>>> > > >> > > >> > > >>>>>> Thanks in advance, > > >> > > >> > > >>>>>> > > >> > > >> > > >>>>>> Siegfried Goeschl > > >> > > >> > > >>>>>> > > >> > > >> > > >>>>>> > > >> > > >> > > >>>>> > > >> > > >> > > >>>>> -- > > >> > > >> > > >>>>> Best regards, > > >> > > >> > > >>>>> Daniel Dekany > > >> > > >> > > >>>> > > >> > > >> > > >>>> > > >> > > >> > > >>> > > >> > > >> > > >>> -- > > >> > > >> > > >>> Best regards, > > >> > > >> > > >>> Daniel Dekany > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > >> > > >> > > > -- > > >> > > >> > > > Best regards, > > >> > > >> > > > Daniel Dekany > > >> > > >> > > > > >> > > >> > > > > >> > > >> > > > >> > > >> > -- > > >> > > >> > Best regards, > > >> > > >> > Daniel Dekany > > >> > > >> > > > >> > > >> > > >> > > >> -- > > >> > > >> Synesty GmbH > > >> > > >> Moritz-von-Rohr-Str. 1a > > >> > > >> 07745 Jena > > >> > > >> Tel.: +49 3641 > > >> > > >> 5596493Internet: https://synesty.com <https://synesty.com> > > >> > > >> Informationen > > >> > > >> zum Datenschutz: https://synesty.com/datenschutz > > >> > > >> <https://synesty.com/datenschutz> > > >> > > >> > > >> > > >> Geschäftsführer: Christoph Rüger > > >> > > >> > > >> > > >> Unternehmenssitz: Jena > > >> > > >> Handelsregister B beim Amtsgericht: Jena > > >> > > >> > > >> > > >> Handelsregister-Nummer: HRB 508766 > > >> > > >> Ust-IdNr.: DE287564982 > > >> > > >> > > >> > > > > > >> > > > > > >> > > > -- > > >> > > > Best regards, > > >> > > > Daniel Dekany > > >> > > > > > >> > > > > >> > > > > >> > > -- > > >> > > Best regards, > > >> > > Daniel Dekany > > >> > > > > >> > > > >> > -- > > >> > Synesty GmbH > > >> > Moritz-von-Rohr-Str. 1a > > >> > 07745 Jena > > >> > Tel.: +49 3641 > > >> > 5596493Internet: https://synesty.com <https://synesty.com> > > >> > Informationen > > >> > zum Datenschutz: https://synesty.com/datenschutz > > >> > <https://synesty.com/datenschutz> > > >> > > > >> > Geschäftsführer: Christoph Rüger > > >> > > > >> > Unternehmenssitz: Jena > > >> > Handelsregister B beim Amtsgericht: Jena > > >> > > > >> > Handelsregister-Nummer: HRB 508766 > > >> > Ust-IdNr.: DE287564982 > > >> > > > >> > > >> > > >> -- > > >> Best regards, > > >> Daniel Dekany > > >> > > > > > > > > > -- > > > Christoph Rüger, Geschäftsführer > > > Synesty <https://synesty.com/> - Anbinden und Automatisieren ohne > > > Programmieren > > > > > > > > > -- > > Christoph Rüger, Geschäftsführer > > Synesty <https://synesty.com/> - Anbinden und Automatisieren ohne > > Programmieren > > > > -- > > Synesty GmbH > > Moritz-von-Rohr-Str. 1a > > 07745 Jena > > Tel.: +49 3641 > > 5596493Internet: https://synesty.com <https://synesty.com> > > Informationen > > zum Datenschutz: https://synesty.com/datenschutz > > <https://synesty.com/datenschutz> > > > > Geschäftsführer: Christoph Rüger > > > > Unternehmenssitz: Jena > > Handelsregister B beim Amtsgericht: Jena > > > > Handelsregister-Nummer: HRB 508766 > > Ust-IdNr.: DE287564982 > > > > > -- > Best regards, > Daniel Dekany > -- Christoph Rüger, Geschäftsführer Synesty <https://synesty.com/> - Anbinden und Automatisieren ohne Programmieren -- Synesty GmbH Moritz-von-Rohr-Str. 1a 07745 Jena Tel.: +49 3641 5596493Internet: https://synesty.com <https://synesty.com> Informationen zum Datenschutz: https://synesty.com/datenschutz <https://synesty.com/datenschutz> Geschäftsführer: Christoph Rüger Unternehmenssitz: Jena Handelsregister B beim Amtsgericht: Jena Handelsregister-Nummer: HRB 508766 Ust-IdNr.: DE287564982
