I am trying to understand the behavior of a classic ASP page, to gain insight into injection vectors by looking at the IIS log and the behavior on a browser.
From the browser, I noticed that sometimes a page is never requested, depending on the spelling in the query string.
For example, https://example.com/test.asp?id=convert() opens the page and I can read the query string using Request.Querystring. Sure it's probably a sql injection vector, but my page reads it (and discards the request).
HOWEVER, https://example.com/test.asp?id=conveert() is never passed to the page. The page does not open, and a totally blank page appears on the browser.
Is the IIS Server pre-processing the query string and "rejecting" some QS's based on spelling? Both requests are in the IIS log with status 200. But only one gets to the test.asp page. Is this normal behavior on the server? The server guy tells me he is NOT filtering for "convert()".
Code example for logging querystring:
Dim conn,incomingQS
Set conn = Server.CreateObject("ADODB.Connection")
conn.Open Application("ConnectionString")
conn.Execute("SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED")
incomingQS = Request.Querystring
incomingQS = DoubleApostrophes(incomingQS)
conn.Execute("INSERT INTO tabLog(qsDate,qsContent) VALUES (getdate(),'" & incomingQS & "')")
conn.Close
Set conn = Nothing
In the IIS log, when the querystring uses "CONVERT", there is an entry in my log. When the exact same querystring uses "CONVEERT", there is no entry, meaning the page is never referenced. Why would that be?
Thanks for any insight here.
Related
I'm reading tutorials on ASP .NET Core and Razor Pages.
One of them, when dealing with the BindProperty attribute, has remarks I find hardly understandable:
Razor Pages, by default, bind properties only with non-GET verbs.
Binding to properties can reduce the amount of code you have to write.
Binding reduces code by using the same property to render form fields
(<input asp-for="Customer.Name" />) and accept the input.
For security reasons, you must opt in to binding GET request data to
page model properties. Verify user input before mapping it to
properties. Opting in to this behavior is useful when addressing
scenarios which rely on query string or route values.
To bind a property on GET requests, set the [BindProperty] attribute's
SupportsGet property to true: [BindProperty(SupportsGet = true)]
(emphasis mine) Source: Introduction to Razor Pages in ASP.NET Core ยง Writing a basic form
I do not understand. Why do extra security measures need to be taken when dealing specifically with GET requests?
As far as I can tell, GET requests are supposed to be safer, not less safe than POST requests, because GET only retrieves data, while POST sends data to the server. So, more often than not, POST requests need extra security measures GET reqs don't need.
And yet now I'm reading that it's fine to do X with POST but careful, don't do this with GET recklessly, you must opt-in and be warned, take precautions!
Why are these warnings necessary? What kind of security vulnerabilities can be introduced by binding GET request data to page model properties? And why are these vulnerabilites not applicable to POST requests?
Binding is two-way model, meaning it binds a given element for both rendering ("show this value here") and submitting back ("save this value there"). For example, you'd use binding to populate an input field with a value that a user could then update and POST back. Binding handles dealing with the value automatically.
If you simply want to display a value, you don't need to use binding at all. Simply make it a public property of your model and reference it directly ({Model.PropertyName}).
There are a bunch of reasons for avoiding [BindProperty(SupportsGet = true)] but I think HTTP's RFC 7231, Section 9.4 covers it well:
URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added to templates when a page is printed, and stored in a variety of unprotected bookmark lists. It is therefore unwise to include information within a URI that is sensitive, personally identifiable, or a risk to disclose.
Authors of services ought to avoid GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. Such services ought to use POST-based form submission instead.
Since the Referer header field tells a target site about the context that resulted in a request, it has the potential to reveal information about the user's immediate browsing history and any personal information that might be found in the referring resource's URI.
I'd like to know if this is even possible. And if it is possible, what the security ramifications would be.
I want to use Javascript to build a dynamic URL to query a Parse-Server database.
It appears that it might be possible based on an earlier Stackoverflow question here and a Node.js doc here
Here's how I envision it working....
So, a user would be sent (via email/Twitter/etc) a link which was created by above method. Once the user clicked on that URL link, the following would happen automatically:
Step #1: User's system would automatically submit a parse-server query.
Step #2: On success, the user's browser would download a web page which displayed the query results.
step one create the pointer value ie the query pseudo-semantic
step 2 insert the pointer value to a text-type field in parse cls=clazz
step 2b mailgun a msg containing a link like :
express.domain.com/#!clazz/:yALNMbHWoy - where 'yA...oy' is oid of pointer row in parse/clazz table
Note that the link is an abstraction only. Its a uri first to express/route && function that will simply get a row from parse.clazz. That row contains the semantic for making a parse query to get back the full DB compliment to pass along to the node template setting up the html ...
in your node/router GET/clazz/:oid will lookup that Parse row in parse/clazz, using the pointer/text value to format a 2nd, Parse query. The query response from the 2nd parse.qry is your real meat ... This response can be used by the express template formatting the html response to orig request on "express.domain.com".
where u ask "download web page" .. that is simply node's RESPONSE to a GET on a route like "GET/clazz".
I have created an Xpage to allow the administrator to input a single Notes Document (They are Contracts) ID into an edit box and press a button to delete the Contract. The delete calls an Agent passing the Contract ID. Below is the button script and then the relevant part of the Agent. What is happening is only the first character is being passed to the Agent, i.e if the Contract ID is 9MXCB4 only "9" is being passed as the Agent message box prints this to the log. What am I doing wrong here? If I hard code a Contract ID after the message box the Contract is processed correctly.
Button code
ag = database.getAgent("DeleteOneContract");
noteid = getComponent("ContractIDDelete").getValue()
ag.run(noteid)
Part of Agent code
Dim runAgent As NotesAgent
Dim deleteID As Variant
deleteID = runAgent.Parameterdocid
MsgBox "Input is " & deleteID
'If line below is uncommented it processes the Contract correctly
'deleteID = "9MXCB4"
' Rest of agent process
....
Note that I have also tried runAgent.Target and runAgent.Query
Just tested that and when I pass it a valid NoteID, the agent reads it just fine. I don't think you can pass any other value than a NoteID to the agent this way.
An alternative might be to use the agent.runWithDocumentContext(doc) method and retrieve the document before sending it to the agent.
I believe that the note ID parameter has to actually be a hexidecimal number in string form. It doesn't have to line up with an actual note ID in the database, but it can only contain 0-9 and A-F (with presumably a cap on size).
To add an extra thought on Jesse's and Mark's correct answers: from AJF's question we cannot tell whether the Xpage is bound to an actual NotesDocument object, or whether it is a (temporary) stand-alone page. In that case, of course, agent.runWithDocumentContext won't work.
But unless you have a good reason to perform the rest of your task using a LotusScript coding: why use an agent in the first place? Why not perform the deletion directly using SSJS code? On the Xpages side of the process you most probably will have to start with SSJS code very similar to Mark's example, but then why not go ahead and finish it off with two or three more lines?
In fact I try to avoid calling agents directly from my Xpages driven applications, due to performance issues, and because I don't like my code to be scattered all over the place.
I need to get the redirected URL or id in JSF using FacesContext. For current URL, I'm using.
String currentPage = FacesContext.getCurrentInstance().getViewRoot().getViewId();
Closest you can get is the referer header via ExternalContext#getRequestHeaderMap():
String referrer = externalContext.getRequestHeaderMap().get("referer");
// ...
You should only keep in mind that this is a client-controlled value and can thus be fully spoofed from client side on (i.e. the enduser can easily edit or even remove it).
Even then, there are cases where the client application won't send it along. For an overview, see among others this question: In what cases will HTTP_REFERER be empty.
Depending on the functional requirement, you'd better manually pass it along as request parameter, or store it in view or session scope.
I have an Express application that gets search parameters and page numbers via query strings.
var name = req.query.name;
var state = req.query.state;
var category = req.query.category;
var pageNum = req.query.pagenum;
What I want is if the search query has a page number and yields no results, to do a search without the page number and pass that back to the client. This works fine, and the front-end is receiving the data correctly.
The only thing is that I want the URL to reflect the changed page number search, so rather than being website.com/search?page=4&state=AL I'd like it to have the page number stripped or changed to 1. I can do this via Javascript on the front-end, but I'd rather have the url changed on the server side (it makes more sense to me at least, rather than having to change every template to do that).
EDIT:
Looks like the only way of doing this is to redirect to the URL without the page query string parameter. It seems this will help me out in getting this done.
I don't quite know your environment, but generally URLs cannot be "changed" on server-side, because they are displayed in the browser on the client-side. The user sees the last whole page request's url. You can only force an URL update (actually a page reload with different URL) from server-side with a HTTP redirect header.
You could check if there are any results for the query with page number, and if not, simply send a redirect to the URL without the page number, so the user sees that extended result with its proper (page-less) URL.
Hope it helps something.