I am trying to perform ajax spider attack in owasp zap. I have set a proxy server in firefox to record. But i have two sites, one normal page and another is API request. Now,when I perform ajax spider in the normal page, only home page is shown but login action is not performed, because it's recorded in site 2. How can I integrate both of the sites to work at the same time?
Please provide me guidance on how can do it!
Also asked (and answered) on the ZAP User Group: https://groups.google.com/d/msg/zaproxy-users/jo9_tyy7XLM/180INyTTAQAJ
In this case you need to AJAX Spider a Context with the authentication
configured (i.e. include in context "localhost:3000" and authenticate
against "localhost:4000"). [1] Having the "login URL" in another server
is not a problem.
[1]
https://github.com/zaproxy/zap-core-help/wiki/HelpStartConceptsAuthentication
I encountered the same problem and I have asked the question ZAP in user group.
When you have two sites for one single application, you need to configure your default context as 1st site, i.e., in your case, localhost:3000 and then use the 2nd site, i.e., your localhost:4000 in authentication section found in default context and perform your test.
Hope this helps!
Related
I'm currently working on a VueJS project on which I've just implemented a SSO system designed by the Portuguese government using our national identity cards, but I'm having some issues parsing the response from the external authentication server.
Here's a small GIF of my problem: https://gfycat.com/threadbarepossiblebagworm
The workflow is as follows:
User clicks on Authenticate.
User chooses "Login via ID Card"
User gets redirected to the external Authentication Provider
User logins with his ID Card.
External Authentication provider then sends back a POST method to the callback URL that is provided.
I read/parse the callback
The issue lies in step 6... The external authentication provider uses the callback URL I provided but I get this error
Cannot POST /users/callback
If this was a typical NodeJS I could just use
router.post('/callback' ....)
Is there a way I can read that callback in VueJS?
I've found this similar issue https://forum.vuejs.org/t/cannot-post-handling-form-post-from-an-external-site/41194/1 but no one managed to offer him a solution.
Thanks in advance!
EDIT: Before you ask, yes, that '/users/callback' is defined on router.ts and if I go to that route it does show a page. It's just not designed for POST methods afaik
Vue is a front-end framework, which means it doesn't have direct access to POST requests by default.
For production, are you running an npm script like "npm run build" and then serving the files that appear in the "dist" folder on a webserver, say Apache? Then you would have to respond to the POST request in Apache.
You could then store their authentication result "farther toward the backend" than Vue and have Vue grab it with vuex.
My objective is to redirect the user to an external site and have them come back to my site but preserve the Trinidad pageFlowScope. This way I can do some processing and state saving in various pages, send them off to the external site for some external processing and then have them come back to my site to finish processing. From the users perspective they'd appear to be doing one continuous flow and possibly be doing multiple of these concurrently in different browser tabs.
The way I'm trying to transition everything, which does work fine except state is not restored, is by doing a post from a page in my flow to the external site and then the external site does a post back to my site in the next page. It's almost like a disconnected ADF task flow executing on a separate server and the returning back into my task flow.
mysite.foo/faces/summary.jsf -> POST externalappserver.foo/faces/startexternal.jsf -> another page -> POST myite/foo/faces/continue.jsf
I've looked all over the place and have found various issues surrounding javax.faces.ViewState but nothing on pulling that out, giving it to an external site, and then having an external site post it back some time later to a different (or even the same) page where it came from originally.
Any ideas on how I can manipulate the state so that I can rendezvous back to my site properly?
I ended up solving this by putting the Trinidad hidden form parameter on the callback URL I passed to the other service. So if my server/app is http://localhost:7001/context/pageout.jsf and it posts to another site with the callback URL, the call back URL is now:
http://localhost:7001/context/pageout.jsf?_afPfm=234z345
This allows Trinidad to restore it's page flow in conjunction with the JSESSIONID cookie provided by the browser. I didn't need to deal with the ViewState field or any other session problem. My pageFlowScope is restored all is well.
A customer of ours has just purchased CQ5 and would like to externalize all of its security. We'd like to use an STS server for SSO and then leverage a custom authorization/attribute provider instead of the CQ5 repository. Ultimately, we do not want to use LDAP in any way.
Here is how we envision this (some pieces already working):
User browses to CQ5 Dispatcher running in Apache
Apache filter redirects user to STS site where login is completed.
User is redirected back to Apache with SAML Claims.
User ID token is placed as cookie into browser. (everything is working up to here)
CQ5 captures that cookie based on the SSO configuration (working)
Problem starts here: From here, we want to call a custom authorization provider for the user's attributes, roles, groups etc...
We have tried to figure out how to do this and can't seem to find the missing link.
Do we need to create a custom login module? Do we need to create a custom principal provider? Do we somehow use the existing LDAP capability in CQ5 but have it call a custom class which leverages the external auth source?
If anyone here has any idea how to do this, their karma quotient would be full for the year if they could share it. I'm not sure if this is a basic thing you do with JAAS or even where to put my classes after I've created them.
We've worked really hard on this so far and seem to be close, but we keep hitting dead-ends.
Thanks so much if you have an idea where to begin!!
-joe
Recent versions of AEM now include the SAMLAuthenticationHandler which allows you to:
Redirect users to SSO to simulate IDP initiated login, or
Allow AEM to perform SP initiated login with IDP
Specify attributes to take from the SAML Assertion and add to the user's profile node (not sure if you can use this for groups)
Specify which groups users should be added to
Set a cookie called request-path that will store the URL the user arrived at, and then redirect them to that location when they're authenticated (ie. deep linking)
This makes relying on the SAMLAuthenticationHandler better than using Apache to redirect. The current version of the handler bundled with AEM 6.2 does not properly set the cookie when using the redirect method, but Adobe does have an updated version that they can provide that will fix that problem.
I normally recommend that clients do not have their own authentication handlers developed inside AEM.
When not using LDAP, this does create an issue where users will not exist until they've logged in. Additionally, when your architecture includes more than one load balanced publisher, it is possible that a user may exist on one server user synchronization.
Try searching the google group for SSO details. Here's one useful post:
http://groups.google.com/group/day-communique/browse_thread/thread/72c235c83a501252/fba4d08a90487156?lnk=gst&q=SSO#fba4d08a90487156
It seems that you will have to implement a custom LoginModule, more information here: http://dev.day.com/docs/en/crx/current/deploying/custom-login-modules.html
I have a GWT app to deploy to Tomcat on a Windows server, with the following requirements:
1- The app should work fully, whether the user is in the Windows domain or not;
2- If the user happens to be in the domain, the app should be able to identify the user in some manner. Presumably, this should be via getThreadLocalRequest().getRemoteUser(), but any other alternative is fine...
3- If the user happens to be in the domain, the app should be able to access the MS Exchange server in that domain, without requiring the user to enter their password.
I've scoured the web high and low for this, but unfortunately, it seems there's no way to get authentication without forcing authentication. There are many examples of exclusions for, say, a login form or other "public" resources, but that won't work for us, since all the resources in a GWT app are packed into the same "page".
Maybe it's my limited understanding that's making me fail in some basic way, but I've tried to look at JCIFS, Jespa, Waffle and SPNEGO, and I just can't seem to get working the way I want to...
Any help would be greatly appreciated.
Cheers,
J.
How about putting a Javascript on your front page and have a Kerberos/SPNEGO protected page. The javascript will attempt to request a protected page, if the user is on the domain you will get the correct result from the page otherwise you will get 401 access denied. In the former case you can redirect your browser to exchange page, or have another AJAX call to retrieve things from exchange server in the later case you either show a log-in form or a generic anonymous page.
What about using JNI to call the Win32Api function LogonUser?
By doing impersonation at the thread level you will have the NTLM token added to the current thread and you would be able to call exchange with no issues
I'm developing a small CMS in PHP and we're putting on social integration.
The content is changed by a single administrator who as right for publishing news, events and so on...
I'd to add this feature, when the admin publishes something it's already posted on facebook wall. I'm not very familiar with facebook php SDK, and i'm a little bit confused about it.
If (make it an example) 10 different sites are using my CMS, do I have to create 10 different facebook application? (let's assume the 10 websites are all in different domains and servers)
2nd, is there a way for authenticating with just PHP (something like sending username&password directly) so that the user does not need to be logged on facebook?
thanks
You might want to break up your question in to smaller understandable units. Its very difficult to understand what you are driving at.
My understanding of your problem could be minimal, but here goes...
1_ No you do not create 10 different facebook application. Create a single facebook application and make it a service entry point. So that all your cms sites could talk to this one site to interact with facebook. ( A REST service layer).
2_ Facebook api does not support username and password authentication. They only support oauth2.0. Although Oauth is not trivial, but since they have provided library for that, implementing authentication is pretty trivial.
Please read up on http://developers.facebook.com/docs/.
Its really easy and straight forward and well explained.
Your question is so vague and extensive that it cannot be answered well here.
If you experience any specific implementation problems, this is the right place.
However to answer atleast a part of your question:
The most powerful tool when working with facebook applications is the Graph API.
Its principle is very simple. You can do almonst any action on behalf of any user or application. You have to generate a token first that identifies the user and the proper permissions. Those tokens can be made "permanent" so you can do background tasks. Usually they are only active a very short time so you can perform actions while interacting with the user. The process of generating tokens involves the user so that he/she has to confirm the privileges you are asking for.
For websites that publish something automatically you would probably generate a permanent token one time that is active as long as you remove the app in your privacy settings.
Basically yuo can work with any application on any website. There is no limitation. However there are two ways of generating tokens. One involves on an additional request and one is done client side, which is bound to one domain oyu specifiedin your apps settings.
Addendum:
#ArtoAle
you are right about every app beeing assighend to exactly one domain. however once you obtained a valid token it doesnt matter from where or who you use it within the graph api.
let me expalin this a little bit:
it would make no sense since it is you doing the request. there is no such thing as "where the request is coming from". of course there is the "referer" header information, but it can be freely specified and is not used in any context of this.
the domain you enter in your apps settings only restricts where facebook redirects the user to.
why?
this ensures that some bad guy cannot set up a website on any domain and let the user authorize an app and get an access token with YOUR application.
so this setting ensures that the user and the access token are redirected back to YOUR site and not to another bad site.
but there is an alternative. if you use the control flow for desktop applications you don't get an access token right after the user has been redirected back. you get a temporary SESSION-TOKEN that you can EXCCHANGE for an access token. this exchange is done server side over the REST api and requires your application secret. So at this point it is ensured that it is YOU who gets the token.
This method can be done on any domain or in case of desktop applications on no domain at all.
This is a quote from the faceboo docs:
To convert sessions, send a POST
request to
https://graph.facebook.com/oauth/exchange_sessions
with a comma-separated list of
sessions you want to convert:
curl client_id=your_app_id \
-F client_secret=your_app_secret \
-F sessions=2.DbavCpzL6Yc_XGEI0Ip9GA__.3600.1271649600-12345,2.aBdC...
\
https://graph.facebook.com/oauth/exchange_sessions
The response from the request is a
JSON array of OAuth access tokens in
the same order as the sessions given:
[ {
"access_token": "...",
"expires": 1271649600, }, ... ]
However you don't need this method as its a bit more complex. For your use case i would suggest using a central point of authorization.
So you would specify your ONE domain as a redirect url. This domain is than SHARED between your websites. there you can obtain the fully valid access token and seamlessly redirect the user back to your specific project website and pass along the access token.
This way you can use the traditional easy authentication flow that is probably also more future proof.
The fact remains. Once the access token is generated you can perform any action from any domain, there is no difference as ther is literally no "domain" where the request is coming from (see above).
apart from that, if you want some nice javascript features to work - like the comments box or like button, you need to setup up open graph tags correctly.
if you have some implementation problems or as you said "domain errors" please describe them more clearly, include the steps you made and if possible an error message.