同源策略和跨域

浏览器的同源策略限制从一个源加载的文档或脚本如何与来自另一个源的资源进行交互。同源是指：协议相同，域名相同，端口相同。同源政策的目的，是为了保证用户信息的安全，防止恶意的网站窃取数据。

非同源限制: 无法读取Cookie、LocalStorage 和 IndexDB, 无法获得DOM, 不能发送AJAX 请求。

C++

输入

在线编程输入输出很关键，特别是输入，输入读数据的方式不对，连测试样例都读不进来，功能实现了，也还是通不过，这里列举一些碰到的例子，慢慢总结。

• cin

cin >> a >> b;, >> 是会过滤掉不可见字符（如 空格 回车，TAB 等); 不想略过空白字符，那就使用 noskipws 流控制 cin>>noskipws>>input[j];

order by 基础知识

ORDER BY {col_name | expr | position}, order by 后面可以跟字段名，表达式和字段的位置，字段的位置需要是整数型。

md5 截断验证

ctf中经常用MD5的截断比较做验证，如:substr(md5($str), 0, 6) === "3322cf",通过这种方式限制脚本的自动化攻击。

通常可以写脚本去爆破MD5, 但是花费时间和比较字符串的长度有关，并且花费时间通常比较长，这不利于脚本自动攻击，下面给出爆破脚本和使用方式。

requests发送前修改请求信息

requests可以再发送请求前，修改请求信息，见Prepared Requests

select 语法

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

SELECT
[ALL | DISTINCT | DISTINCTROW ]
  [HIGH_PRIORITY]
  [STRAIGHT_JOIN]
  [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
  [SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS]
select_expr [, select_expr ...]
[FROM table_references
[WHERE where_condition]
[GROUP BY {col_name | expr | position}
  [ASC | DESC], ... [WITH ROLLUP]]
[HAVING where_condition]
[ORDER BY {col_name | expr | position}
  [ASC | DESC], ...]
[LIMIT {[offset,] row_count | row_count OFFSET offset}]
[PROCEDURE procedure_name(argument_list)]
[INTO OUTFILE 'file_name' export_options
  | INTO DUMPFILE 'file_name'
  | INTO var_name [, var_name]]
[FOR UPDATE | LOCK IN SHARE MODE]]

背景介绍

前端js对用户输入的参数进行加密，然后发送给服务器，服务器先验证合法性，然后才处理用户传入的参数，返回响应。这种方式并没有看起来的那么可靠，完全依赖前端的加密，服务器仅仅只进行验证工作，这是很不安全的，用户只需分析清楚前端的加密方式，然后利用这种加密方式加密数据，就可以伪造数据通过服务器的验证。

2017 0CTF一道Web题KoG就是这种情况, 前端js首先会验证用户输入的合法性，对合法的输入进行加密，服务端进行验证。若想绕过js的验证，可以通过更改js的代码，或者分析清楚js的加密方式，然后利用加密方式伪造数据。

Web安全

• 安全的本质是信任问题
• 安全三要素：机密性, 完整性, 可用性
• 安全评估：资产等级划分 -> 威胁分析 -> 风险分析 -> 确认解决方案
• 基本原则：默认安全原则，最小权限原则，纵深防御原则，数据代码分离原则，不可预测性原则

背景介绍

参加2017 NJCTF比赛时碰见了一道NodeJS的web题，之前也没学过NodeJS, 于是上网搜了一下，搜到了原题 https://www.smrrd.de/nodejs-hacking-challenge-writeup.html, 发现NJCTF在原题基础上改了入口代码，虽说在github上能搜到改过的原题，倒不如直接给源码来的痛快，这里就不提改过的题目了，直接分析原题，其中有几个点还是值得好好学习的。