Is it legal to send custom requests using my own cookie? For example if I login to a website that provides e-mails and I found that I can send a request like: somewebpage.com?email_id=1&cookie_token=123 then can I send a custom request using eg app written in c++ to get all my emails (by changing email_id)?
Related
I've been doing some HTTP methods and header research recently if we should use GET with basic authorization instead of POST when submitting?
HTTP Methods
The GET method requests a representation of the specified resource. Requests using GET should only retrieve data.
The POST method submits an entity to the specified resource, often causing a change in state or side effects on the server.
As we see here, the POST method normally changes the state of the server. If sending out JWTs/HTTP cookies, we are not modifying the state of the server. Nor are we creating a new resource in the server.
I understand that we should not not send the username and password as a GET parameter but should we use the authorization header instead?
Basic authentication
For "Basic" authentication the credentials are constructed by first combining the username and the password with a colon (aladdin:opensesame), and then by encoding the resulting string in base64 (YWxhZGRpbjpvcGVuc2VzYW1l).
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
The only advantage I see to using POST over GET is that we need no extra code in the HTML/JS on the client side to send headers via the fetch API. To send headers, we would need an onsubmit and then check if status code is 200. If 200, we will need to redirect to the page after the login screen. Then again, if using the fetch API, this means the server does not need to send a new HTML page to the client all the time either.
Should we use GET with basic auth or POST when logging in since we don't create a resource/modify the server state?
Would this change if say we enable 2FA since we would need to generate a code for that user?
Doing basic authentication in the browser and using GET is not that recommended.
To do your own login form it is better to always do it using HTTPS and POST. Do post the username/password in the body of the request and secure it with proper CSRF protection.
If you want to level up, you can always look at the OpenIDConnect approach, but that is more advanced depending on your needs.
Also, a good approach is to explore how existing site implement a login form and look at the HTTP(s) traffic in a tool like Fiddler.
UIB Sandbox Access request.
The webhook URL will be receiving a webhook payload as an input.
Get the web hook URL from the application you want to send data
use that URL in webhook section of the application you want to receive data from
choose type of events you want to application to notify you about
I have recorded a login flow of an application and found some URIs like below:
/api/oauth2/initiate GET
/oauth2/authorize GET
/api/v1/oauth2/authorize GET
/api/v1/oauth2/authenticate POST
{"username":"${Username}","password":"${Password}","client_id":"${client_Id}","response_type":"code","redirect_uri":"${scheme}://${host}/api/oauth2/callback","server_id":"${server_Id}"}
When I am hitting above in sequence via JMeter I am getting 200 response. Just like JMeter I tried recording in Postman and it worked same, but instead of JSON it gave response in XML format.
It doesn't generate a access_token, it works via session cookies.
My question is - Do I really have API access or it is just browser record n play? If Yes, Does this mean I can get access to any API, if I am a registered user of that application? For ex: Facebook, YouTube or any startup website.
JMeter works on the protocol level. This means that whatever request you are generating. Say a simple browser request or an API call, you can do that easily.
Now the thing is replicating requests. You don't need to record the requests necessarily using the browser. You need to analyze the few things that are required. Say Postman is generating a request. You specify the things you want to send and you use the API Token there. The same things can be specified there as well. It all depends on how you are understanding the concept of request generation.
You simply need to replicate the samplers and the parameters. And the request headers in postman can be replicated here in the same way.
For each HTTP Request Sampler make sure you add a corresponding child HTTP Header Manager config element.
Headers basically tell the server that what client we are using and in what form data is being sent and then server responds accordingly with the information.
What you're recorded is OAuth2 flow and you won't be able to replay it without correlating the dynamic values.
You can have access to Google API or Facebook Graph API given you have proper access_token but I don't think you should be testing them directly, you should focus on solely your application.
Right now I use the ewsURL to fetch the attachments through a SOAP request. My Outlook Addin gets the ewsURL with a token and send it to the server and the server uses that to get the attachments. The problem is, this does not work for the mobile app. In mobile, I can't get the ewsURL. According to the docs, I have to use the REST API but it's not clear how to use it on the server side. Any help?
On the add-in side, there are a couple of differences when using Outlook REST APIs from an Outlook add-in:
Modify the getCallbackTokenAsync API call to include the isRest parameter.
Use the convertToRestId API on the itemId before sending it to the back-end.
On the server-side, here are some steps on getting started with Outlook REST APIs. The code you use to call the API will be different depending on the server-side language, and there are language-specific steps under the getting started section.
The main difference will be instead of registering the application and implementing OAuth2, you will be able to skip to the step where you use the Mail API (Node.js) and use the REST access token returned by the add-in API.
For calling the attachment API, see the docs for listing attachments on an item and getting attachments.
To test the token returned by the getCallbackTokenAsync API, try making a request like this one:
GET https://outlook.office365.com/api/v2.0/me/messages/<item id>
Authorization: Bearer <REST token>
I'm using a jwt based authentication system and I'd like to ensure that google sends this token back in the header. Is there anyway to give google custom headers to send back to a server?
Not in the header, but you can use the state param to include it in the URL.