Are vulnerability scans aimed at public facing websites or they can be run on password protected websites as well?
Generally there are two types of vulnerability scans Static and Dynamic.
Static Scan:
It is nothing but testing application from inside out by examining code, byte code or application binaries for probable vulnerability.
Dynamic Scan:
It is testing application from outside in by examining application in running state and trying to poke it in unexpected ways to discover probable vulnerability.
Regarding Password protection -
Both of these scans asses password policies used in application. Most of the times static scan analyses for hardcoded passwords inside application, cryptographic mechanisms used in application. Also, dynamic scan assesses weak passwords which are easy to guess, etc. So, major part of password protection can be covered by using both of these scan. However, for more protection, we can rely on third party tools to analyze password policies configured in application.
The scan will generally test your server as a whole, not just the website. It can see what other ports are open, which may indicate a vulnerability. The login page itself might have vulnerabilities.
An automated scan won't be able to spider the site and get all the pages, but that's usually not the point.
Yes they work on both public, and private. Just like what user Garr Godfrey said, it will check the whole hosting server. So as long as the public facing side is on the same host as the protected side they do work the same way.
There are also tools that can yield information regarding a server besides port scans. These are usually known as (site) crawlers here is a link for one.
https://portswigger.net/burp/help/spider_using.html
Related
I observed that the web tool project I'm working on has a potential vulnerability, where a well-forged http form request can make the internal server execute arbitrary shell command.
However, the web tool page is only accessible to my company's internal network and users. Although the attacker can still make a malicious page which forges the request and trap our internal user into clicking on the malicious page, it seems to be difficult for attacker to figure out a well-forged http request without direct access to the webpage. In such case, is that still a serious vulnerability which needs to be solved?
Sorry I'm not very familiar with security. Please let me know if further information is needed.
This is usually a judgement call and handled by company policy.
If your company is small, the entire staff can be trusted and it is certain that the application will never be used in a public setting, you may choose not to address this issue if it is hard to fix.
If any of these is not the case, then you should fix the vulnerability. Often times a formerly internal application becomes public and vulnerabilities are forgotten. Also, consider that an insider may be laid off and use this vulnerability for revenge.
It is always safer to fix the vulnerability. Make the tradeoff wisely.
I am responsible for our corporate application menu page (intranet only). It contains many links to resources (web pages and installed application) and is tailored to the current user.
In the past, I have used an applet to allow installed applications to be started directly from the browser.
The corporate web is going though a revamp and I have been told to find a solution which requires no plugins of any kind.
My first attempt was to register a custom protocol handler. The menu provider contains definitions for all the links and application commands and each user has different rights. I could imagine that, when the menu is created for a user, the commands could be encoded and added as something like custom://base64encodedcommand. The handler would decode the command, perform checks and execute it.
This works well in IE, FF and Chrome. At the moment, we have mainly Windows workstations and it will be used only within the company intranet.
Is this a viable approach? Are there security issues?
Unfortunately with any solution it is possible to only prove the existance of a vulnerability, and never the lack there-of. But there are some necessery, but not sufficient ways to make your system more resistant to attacks.
Currently you are base64 encoding the execution string. This adds absolutely nothing to security. Even if you chose some different method, this will only be security through obscurity, and can easily be reverse engineered by somebody with enough time.
What you can do is to have some sort of public-private key signing set up. So that you can sign each link with your own private key, and that would mean that this link is allowed to be executed, a link without a signature or with an invalid signature should not even be decoded.
So what you would have is custom://+base64link+separator+base64signature.
Things to keep in mind:
It is very important that only you (or very select group of people) have access to private key. This is the same as with any other pub-priv key system.
Not only should you not run the link if the signature is invalid, but you must not even decode it (thus you sign the base64 string, not the decoded command). Assume that it is an attack right away, and probably even inform the user of the fact.
And i repeat, while this can be considered to be a necessary for security, it is not something that is sufficient. So keep thinking of other possible attacks.
I'm interested in using Mylar for an upcoming project.
The promises that Mylar makes seem impressive. However, could a dev write a back-door attack into the code, that is allowed to run (verified by hash/signature), so that the data is compromised (likely via XSS)? Mylar documentation states:
"Mylar ensures that client-side application code is authentic, even if
the server is malicious."
The only way I can imagine this being protected against is for the browser itself to disallow outbound communication of unencrypted data. But, for that to happen, how can the app query the database, make calls back to the server (I understand that Mylar is best used with a browser side framework like Meteor, but still, Meteor needs to communicate with the server for certain tasks).
Is Mylar able to provide complete data security, even from the application developer/server admin?
Here is Mylar's claim (from http://www.mit.edu/~ralucap/mylar.pdf):
3.4 Threat model
Threats. Both the application and the database servers can be fully controlled by an adversary: the adversary may obtain all data
from the server, cause the server to send arbitrary responses to web
browsers, etc. This model subsumes a wide range of real-world security
problems, from bugs in server software to insider attacks. Mylar also
allows some user machines to be controlled by the adversary, and to
collude with the server. This may be either because the adversary is a
user of the application, or because the adversary broke into a user’s
machine. We call this adversary active, in contrast to a passive
adversary that eavesdrops on all information at the server, but does
not make any changes, so that the server responds to all client
requests as if it were not compromised.
Guarantees. Mylar protects a data item’s confidentiality in the face of arbitrary server compromises, as long as none of the users
with access to that data item use a compromised machine.
In this context, 'compromised machine' means the client machine/browser.
After re-reading the Mylar white paper, I see where the document states:
Assumptions. To provide the above guarantees, Mylar makes the
following assumptions. Mylar assumes that the web application as
written by the developer will not send user data or keys to
untrustworthy recipients, and cannot be tricked into doing so by
exploiting bugs (e.g., cross-site scripting). Our prototype of Mylar
is built on top of Meteor, a framework that helps programmers avoid
many common classes of bugs in practice.
Does this mean the way the application was written at the time of encryption, or at the time of attack? In other words, is the encrypted data somehow tied to a specific version of the application code? Elsewhere in the referenced Mylar white paper it indicates that the app code is verified against a hash signature.
If the app code can simply be hacked at the server, this reduces the value proposition greatly, as any attacker who gains access to the source code could modify the code and leach data as it is requested (at the browser). The Guarantee of "protecting confidentiality in the face of arbitrary server compromises" seems broad enough to include the idea of the attacker modifying the source code of the application, hence my confusion.
Also refer to section 6 in the white paper for more information. I believe the Mylar doc is conveying that it does mitigate compromised application code attacks. I'd really love to hear from a dev with authoritative understanding of Mylar.
... could a dev write a back-door attack into the code, that is allowed to run (verified by hash/signature), so that the data is compromised (likely via XSS)?
Yes, a developer could write a back-door into the code. There is no way to prevent that, because a developer could claim he's using Mylar although he doesn't or does use a compromised version. Note that Mylar doesn't say, it could prevent that. It's preventing attacks by server operators, for example if you host your application in a third-party cloud.
3 MYLAR ARCHITECTURE
There are three different parties in Mylar: the users, the web site owner, and the server operator. Mylar’s goal is to help the site owner protect the confidential data of users in the face of a malicious or compromised server operator.
If you don't trust the developers or web site owner, you have to check the client-side source code very time it's loaded.
Mylar documentation states: "Mylar ensures that client-side application code is authentic, even if the server is malicious."
The only way I can imagine this being protected against is for the browser itself to disallow outbound communication of unencrypted data. But, for that to happen, how can the app query the database, make calls back to the server [...]
Is Mylar able to provide complete data security, even from the application developer/server admin?
That's right, the browser won't send unencrypted data to the server (at least the data which you marked as secret). I can't provide a full explanation for how it allows a large subset of SQL functionality on encrypted data, because it's complicated. As Raluca Ada Popa explains in one of her presentations, data is encrypted several times with different algorithms, because each algorithm allows different operations on encrypted data (equality check, ordering, text search, ...). The MIT institute also developed CryptDB, which uses the same methodology but only protects the database server.
3.4 Threat model: Both the application and the database servers can be fully controlled by an adversary [...]
When an attacker controls the application server, he could exchange the whole application with his own, which mocks the original user interface. Here comes the browser plugin into play: The application is signed by the web site owner before it's deployed, so that the browser plugin may check the signature and alarm the user if the application was modified.
You might have noticed that Mylar needs the user to check authenticity himself. Other things that an user needs to be aware of:
Mylar applications must be loaded over a secure HTTPS connection.
Retrieved data must be signed by the expected user (for example a chat room must show who created it and the user has to check if someone tries to fake an existing room).
The client machine must not compromised.
...
Mylar assumes that the web application as written by the developer will not send user data or keys to untrustworthy recipients, and cannot be tricked into doing so by exploiting bugs (e.g., cross-site scripting).
Does this mean the way the application was written at the time of encryption, or at the time of attack?
They assume the application as delivered doesn't contain any bugs which could leak private data. Mylar doesn't prevent coding mistakes, it prevents untrusted modifications later on.
In other words, is the encrypted data somehow tied to a specific version of the application code? Elsewhere in the referenced Mylar white paper it indicates that the app code is verified against a hash signature.
If the app code can simply be hacked at the server, this reduces the value proposition greatly, as any attacker who gains access to the source code could modify the code and leach data as it is requested (at the browser).
Encrypted data isn't tied to a specific version. Each version of the application needs to be signed by the web site owner, so that the browser plugin may check it's signature and attacks would be obvious to users. A common dynamic web site wouldn't allow signing, because each user data is different and would modify the received code, therefore application code (HTML, JavaScript, ..) and data are strictly separated. After the application is loaded and it's signature was checked, data is retrieved via AJAX, whereas the AJAX response must not contain executable code (this is part of the Meteor framework, I can't tell anything about it).
Conclusion
If the web site owner himself is dishonest, you can't be sure about privacy. This is especially the case if governments are able to force the web site owner to cooperate.
Also Mylar doesn't prevent bugs, which could leak data. For example the simplest mistake would be that a developer forgot to mark a field as private.
When an attacker overtakes the application server, users are warned, but if they ignore it (for example they didn't install the browser plugin) their data could be intercepted.
If you want to outsource hosting of your application or you won't trust your own server operators, Mylar provides better security than any other framework I know of.
I'm currently in the process of building a browser helper object.
One of the things the BHO has to do is to make cross-site requests that bypass the cross-domain policy.
For this, I'm exposing a __MyBHONameSpace.Request method that uses WebClient internally.
However, it has occurred to me that anyone that is using my BHO now has a CSRF vulnerability everywhere as a smart attacker can now make arbitrary requests from my clients' computers.
Is there any clever way to mitigate this?
The only way to fully protect against such attacks is to separate the execution context of the page's JavaScript and your extension's JavaScript code.
When I researched this issue, I found that Internet Explorer does provide a way to achieve creation of such context, namely via IActiveScript. I have not implemented this solution though, for the following reasons:
Lack of documentation / examples that combines IActiveScript with BHOs.
Lack of certainty about the future (e.g. https://stackoverflow.com/a/17581825).
Possible performance implications (IE is not known for its superb performance, how would two instances of a JavaScript engines for each page affect the browsing speed?).
Cost of maintenance: I already had an existing solution which was working well, based on very reasonable assumptions. Because I'm not certain whether the alternative method (using IActiveScript) would be bugfree and future-proof (see 2), I decided to drop the idea.
What I have done instead is:
Accept that very determined attackers will be able to access (part of) my extension's functionality.
#Benjamin asked whether access to a persistent storage API would pose a threat to the user's privacy. I consider this risk to be acceptable, because a storage quota is enforced, and all stored data is validated before it's used, and it's not giving an attacker any more tools to attack the user. If an attacker wants to track the user via persistent storage, they can just use localStorage on some domain, and communicate with this domain via an <iframe> using the postMessage API. This method works across all browsers, not just IE with my BHO installed, so it is unlikely that any attacker dedicates time at reverse-engineering my BHO in order to use the API, when there's a method that already works in all modern browsers (IE8+).
Restrict the functionality of the extension:
The extension should only be activated on pages where it needs to be activated. This greatly reduces the attack surface, because it's more difficult for an attacker to run code on https://trusted.example.com and trick the user into visiting https://trusted.example.com.
Create and enforce whitelisted URLs for cross-domain access at extension level (in native code (e.g. C++) inside the BHO).
For sensitive APIs, limit its exposure to a very small set of trusted URLs (again, not in JavaScript, but in native code).
The part of the extension that handles the cross-domain functionality does not share any state with Internet Explorer. Cookies and authorization headers are stripped from the request and response. So, even if an attacker manages to get access to my API, they cannot impersonate the user at some other website, because of missing session information.
This does not protect against sites who use the IP of the requestor for authentication (such as intranet sites or routers), but this attack vector is already covered by a correct implemention a whitelist (see step 2).
"Enforce in native code" does not mean "hard-code in native code". You can still serve updates that include metadata and the JavaScript code. MSVC++ (2010) supports ECMAScript-style regular expressions <regex>, which makes implementing a regex-based whitelist quite easy.
If you want to go ahead and use IActiveScript, you can find sample code in the source code of ceee, Gears (both discontinued) or any other project that attempts to enhance the scripting environment of IE.
I am building a relatively simple program to gather and sort data input by the user. I would like to use a local server running through a web browser for two reasons:
HTML forms are a simple and effective means for gathering the input I'll need.
I want to be able to run the program off-line and without having to manage the security risks involved with accessing a remote server.
Edit: To clarify, I mean that the application should be accessible only from the local network and not from the Internet.
As I've been seeking out information on the issue, I've encountered one or two remarks suggesting that local servers have their own security risks, but I'm not clear on the nature or severity of those risks.
(In case it is relevant, I will be using SWI-Prolog for handling the data manipulation. I also plan on using the SWI-Prolog HTTP package for the server, but I am willing to reconsider this choice if it turns out to be a bad idea.)
I have two questions:
What security risks does one need to be aware of when using a local server for this purpose? (Note: In my case, the program will likely deal with some very sensitive information, so I don't have room for any laxity on this issue).
How does one go about mitigating these risks? (Or, where I should look to learn how to address this issue?)
I'm very grateful for any and all help!
There are security risks with any solution. You can use tools proven by years and one day be hacked (from my own experience). And you can pay a lot for security solution and never be hacked. So, you need always compare efforts with impact.
Basically, you need protect 4 "doors" in your case:
1. Authorization (password interception or, for example improper, usage of cookies)
2. http protocol
3. Application input
4. Other ways to access your database (not using http, for example, by ssh port with weak password, taking your computer or hard disk etc. In some cases you need properly encrypt the volume)
1 and 4 are not specific for Prolog but 4 is only one which has some specific in a case of local servers.
Protect http protocol level means do not allow requests which can take control over your swi-prolog server. For this purpose I recommend install some reverse-proxy like nginx which can prevent attacks on this level including some type of DoS. So, browser will contact nginx and nginx will redirect request to your server if it is a correct http request. You can use any other server instead of nginx if it has similar features.
You need install proper ssl key and allow ssl (https) in your reverse proxy server. It should be not in your swi-prolog server. Https will encrypt all information and will communicate with swi-prolog by http.
Think about authorization. There are methods which can be broken very easily. You need study this topic, there are lot of information. I think it is most important part.
Application input problem - the famose example is "sql injection". Study examples. All good web frameworks have "entry" procedures to clean all possible injections. Take an existing code and rewrite it with prolog.
Also, test all input fields with very long string, different charsets etc.
You can see, the security is not so easy, but you can select appropriate efforts considering with the impact of hacking.
Also, think about possible attacker. If somebody is very interested particulary to get your information all mentioned methods are good. But it can be a rare case. Most often hackers just scan internet and try apply known hacks to all found servers. In this case your best friend should be Honey-Pots and prolog itself, because the probability of hacker interest to swi-prolog internals is extremely low. (Hacker need to study well the server code to find a door).
So I think you will found adequate methods to protect all sensitive data.
But please, never use passwords with combinations of dictionary words and the same password more then for one purpose, it is the most important rule of security. For the same reason you shouldn't give access for your users to all information, but protection should be on the app level design.
The cases specific to a local server are a good firewall, proper network setup and encription of hard drive partition if your local server can be stolen by "hacker".
But if you mean the application should be accessible only from your local network and not from Internet you need much less efforts, mainly you need check your router/firewall setup and the 4th door in my list.
In a case you have a very limited number of known users you can just propose them to use VPN and not protect your server as in the case of "global" access.
I'd point out that my post was about a security issue with using port forwarding in apache
to access a prolog server.
And I do know of a successful prolog injection DOS attack on a SWI-Prolog http framework based website. I don't believe the website's author wants the details made public, but the possibility is certainly real.
Obviously this attack vector is only possible if the site evaluates Turing complete code (or code which it can't prove will terminate).
A simple security precaution is to check the Request object and reject requests from anything but localhost.
I'd point out that the pldoc server only responds by default on localhost.
- Anne Ogborn
I think SWI_Prolog http package is an excellent choice. Jan Wielemaker put much effort in making it secure and scalable.
I don't think you need to worry about SQL injection, indeed would be strange to rely on SQL when you have Prolog power at your fingers...
Of course, you need to properly manage the http access in your server...
Just this morning there has been an interesting post in SWI-Prolog mailing list, about this topic: Anne Ogborn shares her experience...