老生常谈,安全上你不该犯的错!
互联网项目里边,SQL注入漏洞、XSS漏洞和猜测URL攻击这三个漏洞可谓历史悠久,然而直到今天还有人不断中枪,也真是微醺。 这几个漏洞说大也大,说小也小。说大是说这些漏洞危害大,会导致数据层面的安全问题;说小是从技术层面上讲都是未对外部输入做处理导致的,想要做针对性地防范很简单。下面简单看看这些漏洞的原因及防范方法。
低噪声、高可扫读;标题、摘要、来源、标签一目了然。
采集自各技术站点的近期文章。
互联网项目里边,SQL注入漏洞、XSS漏洞和猜测URL攻击这三个漏洞可谓历史悠久,然而直到今天还有人不断中枪,也真是微醺。 这几个漏洞说大也大,说小也小。说大是说这些漏洞危害大,会导致数据层面的安全问题;说小是从技术层面上讲都是未对外部输入做处理导致的,想要做针对性地防范很简单。下面简单看看这些漏洞的原因及防范方法。
我们知道,某些网络运营商为了某些目的,对 DNS 进行了某些操作,导致使用 ISP 的正常上网设置无法通过域名取得正确的 IP 地址。常用的手段有:DNS劫持 和 DNS污染。DNS劫持 和 DNS污染 在天朝是非常常见的现象。一般情况下输入一个错误或不存在的 URL 后,本应该出现404页面,而我们看到的却都是电信、联通等运营商的网址导航页面,正常访问网站时出现电信的小广告,使用了代理却依然无法正常访问某些境外网站,以及最近 Google 几乎被彻底封杀、微软 OneDrive 打不开,这些都和 DNS 有一定关系。
在我早期的设计当中,我靠Photoshop或CSS来告诉我正确与否。如果两个形状在Photoshop标示对齐了,那么它们就是对齐的;如果两个不同的形状是同样的尺寸,那么事实就是如此;如果两个颜色有着相同的十六进制值,那它们看起来就是相同的颜色。 这似乎是合乎逻辑的,但这确是个错误的工作方式。 软件的计算方式是理性的,但是软件却没有考虑人对形状,颜色,尺寸的感知——也就是说软件无法理解物体在上下文中的视觉语言,或者人是如何对物体进行感知的。 人类的非理性思维可以看到并理解电脑无法理解的上下文,因此我们需要决定物体关系在视觉上是否正确。理解这些微妙的不同并知道如何去调整,可以让一个好的设计师更优秀——很少有人主要到它们被调整了,但是如果不调整大多数人又会注意到。
上班编码,加班编码,回到家倒头就睡。别人给结婚同事包红包,他们却从来不用,因为很可能明天就跳槽不在同一家公司了。结婚前衣服都是妈给买,结婚后媳妇包办,自己从没买过衣服,因为不知道该去哪儿买什么牌子。但是他依旧被广大程序员羡慕着,因为……哥们儿成功脱单了呀。
我在Linux下使用vi命令打开桌面的一个hello.ksh文件时,出现Swap file "hello.ksh" already exists!的错误,出现这种错误的原因是Linux下可能同时有多个用户正在编辑一个文件,或者是编辑的时候非正常关闭了,那么再次打开的时候就会出现上面的这种错误。我出现这种错误的原因时,我强制关机了一下。出现这种问题的解决方法如下。。。
使用SecureCRT连接Linux终端的时候,发现对于一些中文字符,老是以乱码的形式出现,并且,在SecureCRT中输入中文的时候,也会自动变成乱码。出现这个问题的原因是编码不对,只要将SecureCRT的编码设置为UTF-8即可。
本文试图从以用户为中心的设计思想解释和探究为什么段首要空两格的问题,其实这个问题也是老生常谈了。 本文主要讨论中文内容呈现过程中要不要在段首空两格的问题。
css3已经“出来”挺久了,由最初的新奇,尝试,到现在慢慢的被习以为常的应用,特别是移动端需求的暴增,对css3更好的支持,吸引更多的人走了进来,但是,对于刚开始接触它的人来说,或许会有很多的混沌之处,毕竟它是个大宝藏,而多数人因应用的局限,了解的面也相对局限。本文就试图给出一个稍大范围的概括性展现。当然,也只是一部分。 一谈起css3,多数人可能首先想到的是各种炫酷的效果。的确,css3的出现的确是使得css的世界有了焕然一新,被解放了的感觉。以前需要用图片的,需要多个标签进行堆叠的,需要用js的,需要用flash的等等,甚至是几乎想不到办法去做的东西,css3都给了我们相应的补偿。 但是,今天我不去从那些方面开始谈,我会按照某种分类把css3来个整体浏览。目的是让对css3不太了解的人能有个大概的了解,我自己也算是复习一下。另外,此文不会列出一堆代码给你看。
安卓第三方应用调起常见问题。
在很多脚本语言中 (比如 Perl 和 Ruby),都有类似 0..3 或者 0...3 这样的 Range 操作符,用来简单地指定一个从 X 开始连续计数到 Y 的范围。这个特性不论在哪个社区,都是令人爱不释手的写法,Swift 中将其光明正大地 "借用" 过来,也就不足为奇了。 最基础的用法当然还是在两边指定数字,0...3 就表示从 0 开始到 3 为止并包含 3 这个数字的范围,我们将其称为全闭合的范围操作;而在某些时候 (比如操作数组的 index 时),我们更常用的是不包括最后一个数字的范围。这在 Swift 中被用一个看起来有些奇怪,但是表达的意义很清晰的操作符来定义,写作 0..<3 -- 都写了小于号了,自然是不包含最后的 3 的意思咯。
因为 Playground 不进行特别配置的话是无法在线程中进行调度的,因此本节中的示例代码需要在 Xcode 项目环境中运行。在 Playground 中可能无法得到正确的结果。 GCD 是一种非常方便的使用多线程的方式。通过使用 GCD,我们可以在确保尽量简单的语法的前提下进行灵活的多线程编程。在 “复杂必死” 的多线程编程中,保持简单就是避免错误的金科玉律。好消息是在 Swift 中是可以无缝使用 GCD 的 API 的,而且得益于闭包特性的加入,使用起来比之前在 Objective-C 中更加简单方便。在这里我不打算花费很多时间介绍 GCD 的语法和要素,如果这么做的话就可以专门为 GCD 写上一节了。在下面我给出了一个日常里最通常会使用到的例子 (说这个例子能覆盖到日常的 GCD 使用的 50% 以上也不为过),来展示一下 Swift 里的 GCD 调用会是什么样子。。。
今天在微博上看到有大神发表了关于沙箱逃逸技术的文章针对沙箱检测的逃逸技术小讨论,让我想起来我也还有几个有意思的小技巧,所以也来凑个热闹。需要声明的一点是,本文将要讨论的问题是我很久之前所做的总结,当前是否有效我没有去验证,所以,如果你实际测试的时候发现方法失效了,也请保持冷静!
在iOS 6中,以前工作正常的访问通讯录的iPhone程序可能会出错,现象是程序启动时不提醒用户是否允许程序访问通讯录,同时在“设置->隐私->通讯录”中看不到你的程序。iOS 6加强了通讯录访问控制,要求开发人员显式声明需要访问通讯录,方法是调用 ABAddressBookRequestAccessWithCompletion方法。
对程序员来说,学好“英语”而不是“专业英语”是非常重要的。只学好专业英语,看得了技术文档,但那一大堆专业术语和概念可能会像陨石一样,没来由地坠落下来,只能生吞活剥地硬背。如果学好英语,你才会有融会贯通的感觉,知道那些术语和概念原来是从地里长出来的,底下连着根茎。
CSS 的完整英文名称是: Cascading Style Sheets, 级联样式表. 除了可以定义丰富的样式, 以及进行界面控件布局外, CSS 最重要的特性便是名字中的"级联(Cascading)"一词. 级联代表了父子关联, 天生便是和数据结构中的"树"相关的. 我创建的 CocoaUI iOS UI 框架, 是一个使用 CSS 进行 iOS 上流式布局的开发框架, 极大地方便了 iOS 应用的界面开发, 轻松适配多种屏幕. 因为 CocoaUI 使用 CSS 来进行界面布局和定义界面样式, 所以需要对 CSS 的样式规则进行匹配, 将某一条 CSS 样式作用到某一个 UIView(IView) 上面.
过年回武汉家中,只有一台 2000 块的一体机可以用,自然是跑不动 3d 游戏的。我挑了一款 Invisible Inc 玩,居然很流畅。 这是款 XCOM like 的策略游戏,场景是 isometric 的。但是用 Q E 两个键可以旋转场景,虽然静止下来只有四个方向,但是旋转过程却以动画方式呈现。这让我一度认为它的场景是基于 3d 模型制作的。但令人惊讶的是,在低配置的一体机上却非常流畅。相比较,我最近在玩的 XCOM 2 却在 GTX 550 显卡上也有卡顿。 我仔细观察后,发现其实 Invisible Inc 的场景里的物件都只是 2D 图片。甚至只有正面和背面两张图,通过左右镜像得到了四个视角。它的旋转速度很快,并加了一定的模糊效果,欺骗了人眼。其实只有地板和墙壁是真正旋转的,其它物件只有坐标在做旋转,而图片本身在旋转过程中并没有变化。 也就是说,它的引擎其实是基于 2D 制作的,模拟出了 3d 才有的视觉效果。
最近在做一些性能优化工作,回想起工作这些年来,参与过的三次集中性能优化,每次都得折腾少则一个月,多则半年。这些内容既是不同视角、不同思路的比较,也是挺有趣的工作经历。
基类中为了方便原则, 一般会加载所有可能用到的属性到 Context 中, 但这会导致性能问题, 所以需要 lazyload 机制. 例如, 某些属性只有在子类中被用到时, 才会真正地去查询数据库, 如果子类中不使用这些属性, 则不会发生数据库请求。
在iOS系统,使用Url Scheme框架在APP间互相跳转和传递数据,本文只介绍如果检测和跳转。
虽然Oracle数据库的故障千奇百怪,甚至让客户有种防不胜防的感觉,但还是有很多故障是比较常见的,这些问题也是我们Oracle服务部门在客户现场经常遇见,也经常处理的问题。 事实上,针对这些常见问题,Oracle公司不仅提供了诊断和解决问题的思路和方式,甚至针对具体问题,提供了专门的官方处理文档。如果我们能在平日的运行维护工作中,提前预读这些文档,甚至自己编写相应的故障处理手册,一旦这些常见故障真正发生时,我们就不会那么手足无措,即便不一定完全胸有成竹,也至少可以做到一定的心中有数了,就像打仗一定要有作战预案、一定要打有准备之战一样。 本章就将介绍这些常见故障的诊断和处理过程。例如ORA-00600、内存不够、数据库空间不够、snapshot too old、UNDO表空间无法扩展等。