I'm trying to implement Negotiate (at least the Kerberos part) in a small web server. I've figured out how to get a client to send me a Kerberos Negotiate Authorization header. I've figured out how to decode that data (ASN.1). I cannot figure out how to turn this into a WindowsIdentity. I can get a general idea of how I might from KerberosReceiverSecurityToken, but I can't find anything like a NegotiateReceiverSecurityToken. I've been digging through lots of DLLs and I can't for the life of me figure out where IIS/.NET processes the Negotiate header.
I presume (if I had my own SspiWrapper) that I would do something with SspiWrapper.AcquireDefaultCredential("Negotiate", CredentialUse.Inbound) to acquire an SSPI context with which I could call AcceptSecurityContext/Negotiate and then use QuerySecurityContextToken to get the token with which I could create a WindowsIdentity.
But KerberosReceiverSecurityToken makes that look like an immensely complicated process. And without any idea of how to do that or what part of the Authorization header payload to put into it, I could probably beat my head against it for a month without getting anywhere.
(Before you ask or answer, I have absolutely no interest in using the built in Negotiate logic. If I could find it, I would learn from it, but I've been trying to get that to work for FAR to long. And I'm done with that.)
Parse the incoming response token
Call Secur32.AcquireCredentialsHandle to get a handle
Call Secur32.AcceptSecurityContext passing the handle and the token
Call Secur32.QuerySecurityContextToken passing the security context
Construct a new WindowsIdentity(hToken) using the output form step 4
If you have any questions about any of these steps, I can elaborate and/or provide some sample code.
Related
Morning all,
I've not posted on SO for quite some time, but I need to ask the question, I’ve spent a day and a half trying to get this to work - it’s super frustrating considering I managed to implement v2 with posting a tweet in 2 - 3 hours but because I need the media endpoint (does not exist in v2), I rebuilt my flow into v1 to upload media.
Ok, so my app allows the user to authenticate with twitter and tweet/upload media. I’m using (I think) the 3-legged oauth flow.
Currently, the flow is :
https://api.twitter.com/oauth/request_token - 200 status code and I
confirm the callback URL
I use the access token from step 1, and then call/redirect
https://api.twitter.com/oauth/authorize?oauth_token={accessToken}
this obviously redirects to my endpoint.
I extract the oauthToken and oauthVerifier and call:
https://api.twitter.com/oauth/access_token, this returns an
oauthToken and oauthTokenSecret, I store the values.
All of the above conforms to what is in the docs, but when I use the stored values from step 3 to post a tweet I get unauthorized.
The signing logic works because it’s what’s used in “Request access token” - with a couple of changes.
I'm learning more towards a flow issue due to trying various nuget packages(tweetinvi in particular) and I get exceptions in those too.
Any help is greatly appreciated.
Not really an answer per-se, but rather notable actions.
At this point in time, you cannot upload media with V2 of the API, whilst you can integrate quite quickly and send a tweet, it's almost pointless without media.
So, you'll need to build/integrate with V1.
The unknowns and curve balls:
The most important! V1 requires elevated access! Which you'll need to
apply for, not all get accepted! but V2 just integrate and tweet with
no elevated access - very strange.
Always ensure to read the resp correctly, and try few times in code, postman,
fiddler etc. Whilst the resp contains a collection of errors object,
you'll never get a collection of errors.
If you're not using any sort of package/library, pay close attention
to crafting the request signature - it's a pain.
I know how anti-forgery token in ASP.NET MVC works.But still not clear about few scenarios. One I mentioned below.
submit a post request with below information
cookie token(antiforgerytoken)
form data(first name & last name)
form input hidden token(antiforgerytoken)
Before reaching server a hacker modified form data(first name & last name) leaving token info unchanged.
In this scenario, how we can make sure the data submitted securely reached server without any modification
Actually this question is asked by an interviewer. I discussed with my colleagues and I searched in Google too. Since I couldn't find a clarity on this I thought to ask here.
I am not sure if this is a valid question.If yes,any help would be appreciated
Multiple things are mixed here. The confusion is around the purpose of different protections, so let me try and get that straight.
CSRF, and antiforgerytoken
The basic threat is the following. A victim user is logged on to the victim website victim.com. Meanwhile (say in another browser tab) he visits a malicious website malicious.com that wants to exploit CSRF in victim.com. For that, malicious.com has the user post the required parameters to victim.com to call a certain function which obviously victim user did not want to perform. This is the base case of CSRF, exploiting an existing user session, malicious.com performed something on victim.com via a victim user.
This is prevented, if for example antiforgerytoken is used, because malicious.com will not be able to send the right token to victim.com, so the request will be denied.
Note that this has nothing to do with legitimate request content.
Integrity of requests
A different problem is making sure the request is received as sent, ie. data is the same. This is usually achieved by using HTTPS, which provides message integrity and encryption (among others). So if HTTPS is used, such change of data in transit is not possible.
Of course if the attacker controls either the client or the server (more precisely, the TLS endpoint, which is not always the server), ie. anything outside the TLS channel, then the attacker can modify data. But that would mean having control over the client. For example you can do this if you run a local proxy (Fiddler, Burp, ZAP Proxy, etc.) on your client - you can then change any data in the request, that's how penetration testers work. However, an attacker not having this level of control would not be able to do this.
Without HTTPS, request (and btw also response) integrity and encryption are problems that are hard to solve. The solution is HTTPS. :)
I have a WCF REST service hosted in SharePoint that uses SSOM. The client web application sends AJAX requests containing the REQUESTDIGEST in a X-RequestDigest header. I am using the typical SPWeb.ValidateFormDigest() for my POST requests to prevent CSRF vulnerabilities. Works great.
Here's the weird part. Our client uses HP Fortify, and it is reporting that our GET requests are vulnerable to CSRF attacks. My GET requests are indempotent so this seems silly, but I must be compliant.
To get around it, I want to use ValidateFormDigest() in my WCF method for the GET request the same way I do for POST, but it throws this exception:
"Updates are currently disallowed on GET requests. To allow updates on a GET, set the 'AllowUnsafeUpdates' property on SPWeb."
I tried setting AllowUnsafeUpdates, but that just makes the request succeed without validating the digest!
Is there a way to have SPWeb validate the digest within a GET request?
HP Fortify gives recommendations, not edicts. If you think - and can prove - that the warning is spurious, then justifying the pattern should be treated as being compliant. Code analysis tools are not perfect.
I'm trying to get a SAML token from an ADFS instance. I followed the example found here (http://blogs.msdn.com/b/willpe/archive/2010/10/25/windows-authentication-adfs-and-the-access-control-service.aspx) to configure everything. The ADFS instance is configured by a different party, but setup as found in the article.
At first sight, it all seems to be working ok. But when I go into code and run a sample which should get me a token, I receive a (411) Length Required) response from the server. It doesn't matter much if I switch endpoints, errors stays the same. Seems like the response isn't even getting to the endpoint at all.
The Length Required error seems to have something to do with a missing Content-Length: 0 header line. I checked with Fiddler; it's not there. But the call is generated from within the .NET framework, so there really isn't that much I can do about that.
Any idea why the server might throw this error? Should I try to change the request, or disable the check on the server side? Or an option I haven't thought of perhaps?
I have a c# "client" and a Java "server". The java server has a wsdl it serves to the client.
So far it works for c# to make a request for the server to perform a soap action. My server gets the soap request executes the method and tries to return the result back to the client.
When I send the response to c# however, I get "The server committed a protocol violation. Section=ResponseStatusLine".
I have spent all day trying to fix this and have come up with nothing that works. If I explain what i did, this post would be very long, so I'll keep it brief.
i Googled for hours and everything tells me my "response line" is correct. I tried shutting down Skype, rearranging the response line, adding things, taking things away, etc, etc. All to no avail.
This is for a class assignment so no, I can not use apis to help. I must do everything manually on the server side. That means parsing by hand, creating the soap response and the http response by hand. Just thought you'd like to know that before you say to use something that does it for me.
I even tried making sure my server was sending the correct header by creating a java client that "mimicked" the c# one so I could see what the server returned. However, it's returning exactly what i told it to send.
I tried telling my java client to do the same thing but to an actuall running c# service, to see what a real service returns, and it returned basically the same thing. To be safe, I copied it's response and tried sending it to the c# client and it still threw the error.
Can anyone help? I've tried all i can think of, including adding the useUnsafeHeaderParsing to my app config. Nothing is working though. I send it exactly what a real service sends it and it yells at me. I send it what i want and it yells.
I'm sending this:
"200 OK HTTP/1.0\r\n" +
"Content-Length: 201\r\n" +
"Cache-Control: private\r\n" +
"Content-Type: text/xml; charset=utf-8\r\n\r\n";
The reason for your error is that you've got the status line syntax wrong. According to the RFC, the status line syntax is:
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
You got the parts of the response status line around the wrong way ... like the error message is telling you!
Some advice:
Don't try to talk HTTP or SOAP at this level. These protocols are complicated, and there are existing well-implemented, well-document libraries that do this kind of thing. Use them and don't waste your time reinventing the wheel.
If you really do want / need to implement this stuff yourself, it is CRITICAL that you read and understand the relevant specifications. They are easy to find using Google.
(I'm not going to provide links because that would only encourage you to waste your time on building the software equivalent of horse carts with square wheels. because you need to learn to find and use them yourself ... as a matter of course.)