How to automate logging in and retrieve data? - http

I want to automate logging into a website and retrieving certain data.
I thought the way to do this would be to sniff the HTTP requests so I know where the login form is being POSTed to so I can do the same using NodeJS/Java/Python.
However I can't seem to find the HTTP request that handles it.
The site seems to use some Java-applet and a lot of Javascript.
This is the site: link
Should I have a different approach?
Also also wonder about storing a cookie session, and sending it with each HTTP request after logging in.
I'm sorry if I am not to clear, I will try to explain myself further and edit this post if needed.

You can use the developer console (hit F12) in Chrome (this works also in other browsers) and then click the "Network" tab. There you see all network calls.
To detect what http requests are performed from a mobile device, you can use a proxy like Charles Proxy.
Also be aware that if you post from nodejs the cookies won't be set in the users browser.

Related

Do Desktop apps need HTTP preflight requests?

I'm developing an app that needs to get info from a third party API. I've been developing it to be a web application with Vuejs. For the requests I tried to use axios, jquery and the fetch API, but I'm having trouble with the preflight requests, it seems that the API is not treating the OPTIONS requests properly and it throws me a 405 error (I made a GET request on the same url through Postman and it worked normally and I also edited a OPTIONS request on firefox network panel to become a GET request and it returned a 200 status).
Now I'm thinking of abandon the idea of the web application and work it as a desktop application, but I need to know if the preflight requests are going to be a default behavior in this kind of app too.
Thanks for your attention!
No, CORS preflight requests are made by browsers, and are necessary due to the browser security model. They would not be used by a desktop application.
You can easily test this with curl, postman, etc. It sounds like you tried this, but the details you've described are off. Don't change anything to GET. Use the actual request you're trying to make, but do it outside the browser context. If the API responds appropriately then it should work in a desktop application.

Block http requests not submitted via UI

This might seem like a strange question, but is it possible to detect and reject requests sent to my web server from outside my UI? For example if someone sent a post request to create a resource using the correct authorization token or session info from a tool such as Postman, could it be detected?
I want to prevent someone from using my application as some makeshift API.
Probably the best you can do is to just make sure (or come close to that) it's a human being by using a captcha service such as reCaptcha

HTTP redirect from MS Access

In my web application, there's a link sending a redirect (302 to another GET request) together with some cookies. It works fine, except when used from MS Access by a guy I remotely work with. I know close to nothing about what and how he does, I only know that he uses Application.FollowHyperlink.
The link from Access should be opened in a browser, but after the redirect, there seem to be no cookies there. When used normally, there's no problem. Can it be like that Access handles the link itself and sends the redirected URL to the browser?
Maybe a stupid question, but I have no idea about Access (never ever seen it) and I'm sitting only on the server side. There's nothing interesting in the server logs...
The problem was MS doing some complicated things like here instead of simply opening an URL in a browser. Access accesses the page, sees the new URL, and gets and eats all cookies. While digesting the cookies, it points the browser to the new URL. The browser has no cookies and no access to anything.
This summarizes it nicely:
This problem occurs because of missing session cookies for the Web server. This problem is specific to certain Web-server designs that depend on cookie information instead of authentication information or that depend on cookie information plus authentication information.
To me it sounds like "works with MS only", though I'm not exactly sure what "authentication" they mean.

Why Fiddler can not inject javascript on certain domains?

I am using Fiddler to inject a javascript library onto the page using:
oSession.utilDecodeResponse();
oSession.utilReplaceInResponse('</head>','<script src="//third_party_domain.com/js_file.js"></script></head>');
What would be the reason why this would not work on a certain secure (HTTPS) domain? It seems to work on every other domain I try this on (http and https).
I think it is related to Fiddler, as I know this has worked in the past - so perhaps it's a configuration setting I'm missing?
Fiddler can not read HTTPS pages unless it is configured to decrypt them. Check the checkboxes below on the HTTPS tab in Fiddler's options.
Details

Embedding User + Password data for HTTP Basic Access Authentication in Querystring

We're trying to test an API that requires HTTP Basic Access Authentication credentials (http://en.wikipedia.org/wiki/Basic_access_authentication) in the request.
Ideally, we could just test the API using a web browser by putting all API parameters in the URL querystring, but we haven't yet found a way to encode the HTTP Basic Access Authentication credentials (username and password) in the querystring.
Does anyone know a way to do this?
Thus far, we've tried:
https://username:password#mydomain.com/
...without success.
username:password#url authentication has been disabled in many browsers for security reasons.
For example in IE:
Internet Explorer does not support user names and passwords in Web site addresses (HTTP or HTTPS URLs)
As far as I know, there is no way to circumvent this if this is blocked. It's possible that this can be turned of in Firefox using a setting in about:config. Or use some other browser that doesn't block it - I don't know which ones do and which don't.
Alternatively, consider building a quick web form that submits the option to a server-side language (e.g. PHP) that makes the request, or use a command line client like wget to send the requests. The latter might even be easiest

Resources