Cross Site Scripting for .exe?

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

I'm a newbie but from what i've read, most of the Cross Site Scripting
vulnerabilities are associated with the .jsp, .asp, .htm etc. But i'm
looking at a particular case of security testing where the forms
containing user input post to a .exe. This .exe is under the /cgi-bin
directory. What does this exactly mean? How can an exe take in these
posted inputs?
Also, If i put in any scripts into the user input field, after posting
of this data to an exe, i get an error page which just lists the error
number and no other info...How do i find out if my script has been
executed or is there some other exploit i can use for a .exe ?


Re: Cross Site Scripting for .exe? wrote:
Quoted text here. Click to load it
Sounds to me as if you are attempting to exploit the exe called by the
post cgi script.

Depending on input checking and permission levels you very likely can't,
to the best of my knowledge, if it is done properly.  That is the
general idea to defeat folks trying to doing unions and such with error

The error message (number) thrown probably, depending on method, does
not mean anything except to the help desk for the application so they
can identify easily what the users issue is.  The error message does not
come from the DB but from the exe.  It means your method has been

Sounds to me like your approach may very well can not succeed.  Congrats
to the folks who understood the vulnerability of many HTML applications.
  That exe that is called by the cgi script handles several procedures:
    1. It determines if the input is valid and does not contain chars that
indicate a delimiter in the input.  It also validates the input length
does not exceed define parameters (prevents buffer overflows)

    2. After the exe has validated the input string it places the
validation sequence verifier in the commo string as well as applies the
encryption template (probably used if they were astute enough to do this
properly) so the data can be passed to the DB server.  This reduces the
probability of successful access to the DB if the web server is compromised.

    3. Formost purpose of the exe is to place a boundary between the DB and
the application user.  DB error messages should never be thrown to the
user.  This exe acts as a middle man to prevent this activity from
occurring.  Unknown to you is another exe that filters the db input to
the web server to ensure the error (or other information you want to
keep secret such as the db schema) is never passed as data to the

SQL injection is a major issue with many web applications.  These
methods are designed to prevent access.

Once folks understand the threat from injection, the methods used to
prevent SQL injection is simple enough.

I suspect "if" the application allows file posting, you will find the
webserver input file input file from the DB checked for other keyword
activities.  Once it is set up, it is actually simpler for the
application programmer to utilize these secure methods as the exe
handles the DB calls, not the application.  This eliminates another
subset of exploits such as DB access data strings, algorithmic key
methods, and encryption template data from being easily revealed.

I assume you are hacking this site because you do not know what the exe
is or the meaning of the error code (arbitrary).  This is by design to
prevent you from doing what you are attempting to do.  I would expect
you will find at this site all of their input methods covered by this
same technique.  Usually once this issue is understood, one goes through
site with fine tooth comb to ensure these methods are prevented. Even if
you compromise the webserver and gain access to the exe (which should
trip a number of tripwires) you still will not gain access to the db
because of methods used to synchronize the db communication. If all
sites used these methods, we wouldn't have all the credit card
compromises that certain (expletives deleted) attempt to access what
they have no right to access.


Re: Cross Site Scripting for .exe?

Quoted text here. Click to load it

If the executable resides in the cgi-bin directory, then the executable
*is* callable as a CGI.

Quoted text here. Click to load it

And yet PHP sites do this all the time.

Quoted text here. Click to load it


Re: Cross Site Scripting for .exe?

Looks like CGI C has been used. I looked up the net but could not find
much info on vulnerabilities of CGI C.  Anybody know where I can obtain
such info? I want to test all aspects of the site. Can anyone tell me
where I could find a comprehensive document of scripts/exploits I
should test for? The internet is scattered with bits and pieces, but I
havent come across any doc which sums up all such scripts.

Thanks in advance!

Site Timeline